Wikipedia:VisualEditor/Feedback/Archive 2014 4

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.

Is there a way to add or change a template description?

Tracked in Phabricator
Task T71866

When editing Hepburn romanization#Hepburn romanization charts using VE, I can double-click on the word "red" and it opens a popup that reads "This template changes the color of any supplied text to red." (Very handy!) When I double-click on the word "blue" below it, a popup opens that reads "You are adding the "Blue" template to this page. It doesn't yet have a description, but there might be some information on the template's page." If I wanted to change that description to something more descriptive, like exists for "red", is there a way to do that within VE? 28bytes (talk) 14:06, 21 August 2014 (UTC)

@28bytes: Template pages can't be edited with VE, either natively or via the template dialog. Personally, I think it would be a mistake to add such functionality to the dialog, since mucking with TemplateData isn't something we want relative newcomers to do. (Consider the length of the documentation at Wikipedia:VisualEditor/TemplateData.)

On the other hand, it would be nice if there was a way for editors to post a comment or request on a Template Talk page, directly via VE, rather than having to do this as a separate edit (assuming they can figure out how to).

It would also be nice if the system were to gather (queryable) data for which templates have been seen (and with what frequency) in the VE template dialog where such templates lacked TemplateData.

Finally, fyi, I've added TemplateData for the template {{blue}}, at the page Template:Blue/doc, and did the same for the other color templates lacking TemplateData. -- John Broughton (♫♫) 17:31, 21 August 2014 (UTC)

Thanks John. I like your idea about gathering stats for TemplateData-less template views; that would be a great report that people could use to prioritize which TemplateDatas need to be added. 28bytes (talk) 17:57, 21 August 2014 (UTC)

Filed as bugzilla:69866. —TheDJ (Not WMF) (talk • contribs) 18:24, 21 August 2014 (UTC)

Related news: The "required" parameter is going to actually mean "required" eventually, so any templates that are "requiring" wjen they ought to be "suggesting" need to be corrected. In a few weeks, missing "required" parameters will start producing warnings (but you'll still be able to save the page). Whatamidoing (WMF) (talk) 23:36, 26 August 2014 (UTC)

Possible Bug

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	I was adding information to the article and citations to back it up.
Steps to Reproduce:	Added citations via the cite pulldown. Saved article. Looked at article, saw that, although it had added the inline citations where I'd put them, there was nothing in the reference section. I realised that this was because it lacked a reflist.
Results:
Expectations:	Before, adding citations to an article with no reflist caused the saved page to have a "this page contains no reflist" (or similar) warning appear. This warning was absent.
Page where the issue occurs	Before I added anything: https://wiki.riteme.site/w/index.php?title=Ricardo_Santos&oldid=619431567 After I'd added the in-line citations: https://wiki.riteme.site/w/index.php?title=Ricardo_Santos&diff=prev&oldid=622648793
Web browser	Chrome
Operating system	Windows 8
Skin
Notes:
Workaround or suggested solution

Red Fiona (talk) 20:39, 24 August 2014 (UTC)

This is due to a recent change to MediaWiki software. Pages no longer display the ugly red warning label. There's a tracking category at Category:Pages with missing references list so that people can find and add missing reference lists as needed. Whatamidoing (WMF) (talk) 23:06, 25 August 2014 (UTC)

Cool, I thought I'd done something to break it. Would there be any way of having a less "ugly" label? I think the warning is a good idea because more experienced users can fix a little oops like that in a few clicks, rather than causing more work for people.Red Fiona (talk) 02:37, 26 August 2014 (UTC)

I don't know. I didn't follow that discussion, but I believe that the goal was to remove any error that would be visible to readers, so they probably wouldn't accept anything that just displayed on the page. You probably couldn't use an edit filter (to warn you when you saved the page), because I think that would trip every time you edited a section in the wikitext editor. VisualEditor might be able to warn you, but (a) what if your wiki's convention was to always rely on this automatic ref display and (b) what if you're using ref templates that actually do work, but VisualEditor doesn't know about? You can set your account to display hidden categories, but would you really notice that one, out of all the others, at the end of a possibly quite long page? (I wouldn't.) Perhaps someone else will have ideas about how this could be made more visible to you. Whatamidoing (WMF) (talk) 23:43, 26 August 2014 (UTC)

What's the current status on the look and feel of image slugs?

I just bit a new editor by using Visual Editor to clean up their article, and managed to delete three images in the process. The edit is [1]. As you may be able to see if you open Visual Editor on the "before" image, the images themselves are off-screen, and the image slugs are invisible. Mac Chrome. I saw a note in the comments for (resolved fixed) bug 47790 that there was some thought at one point about making these more visible in general, but I couldn't find more information on what the current plan is to try and avoid this sort of UI difficulty?

This is a really easy error to make on new editor AfC submissions, since excessive vertical space is a common feature of such drafts. --j⚛e decker ^talk 21:21, 17 August 2014 (UTC)

I'm really glad you posted this, I nearly just made the same mistake myself and only didn't because I read this first. I still don't know what an image slug is though, presumably it's not one of these. SpinningSpark 08:59, 18 August 2014 (UTC)

It's a known problem. I'll ask what the current status is. Do you have any suggestions for what it should look like? Whatamidoing (WMF) (talk) 20:48, 18 August 2014 (UTC)

Well for sure rendering it as a blank line is about the worst possible thing to do. That positively encourages editors to delete it, while rendering it invisible (like it is in the article) will most likely be left alone (unless a block spanning a paragraph boundary is deleted). If the line is going to be rendered it should have an icon on it so we know that it is an image. A better approach in my view though is to render exactly as in the article, but not to delete any images unless they are positively selected. That means that if a block of text is selected and deleted (or copied, or moved), any embedded images should not be deleted, copied or moved. If it is intended to delete the image as well then select it with Ctrl-select. By the way, Ctrl-select allows non-contiguous portions of text to be selected but only one actually gets deleted on pressing delete. Seems like another bug (ed:Bug 69737 raised) to me. SpinningSpark 02:21, 19 August 2014 (UTC)

Whatamidoing, I'm honestly not sure. I'm used to working in systems that have a variety of kinds of slugs that need to be differentiated (visual HTML code editors, page layout tools, etc.), and part of me expects something looking like an image icon. But I may very well not be the average user. Hmm. --j⚛e decker ^talk 18:21, 21 August 2014 (UTC)

Thank you both for these comments. I am thinking about what you've said. I'm not sure that I could make a mockup, but what we've got now pretty much looks like this:

(blank slugs because the image or other node that you've unknowingly selected is off screen), and what I'm thinking about is more like this:

[Icon] File:Example.jpg

with the icon and the label matching whatever is being displayed in the little box underneath the selected item (except displayed where the wiktext is located/where you're looking, rather than only off screen/under the image). What do you think? Would it be helpful? (I have no idea if it's technically feasible.) Whatamidoing (WMF) (talk) 23:29, 26 August 2014 (UTC)

That's way better than a meaningless blank line, but I stand by my original comment as the ideal solution. SpinningSpark 23:54, 26 August 2014 (UTC)

Clicking on a template making a link goes to that link

Tracked in Phabricator
Task T72074

When you click on a template that makes a link, like {{good article}}, it sends you to that article. This means you can not select and edit these templates, and it is generally annoying and confusing:Jay8g [V•T•E] 00:32, 24 August 2014 (UTC)

@Jay8g: When I add {{good article}} (anywhere), I then see a template box (icon plus name) in the upper right corner. I can click on that to edit the template (though editing this particular one is pointless - it has no parameters).

I note that there may be a problem with this particular template, however: when I used VE to edit the (good) articles Serpens, I only saw that template box in the upper right corner once; in subsequent edit sessions, it was missing. I can do a screen print if no one else can replicate this. (Mac, Vector, three different browsers)

I wonder if you're seeing a link because you have selected the gadget that makes one (and thus the link isn't a VE issue). Have you selected (turned on) "Display an assessment of an article's quality as part of the page header for each article"? (It's in Preferences > Gadgets > Appearance section) -- John Broughton (♫♫) 03:56, 24 August 2014 (UTC)

John Broughton: It's not the gadget link, but the one in the template, that is opening. This happens on other teplates, such as {{pp-semi-vandalism}}, as well. I have not gotten around to checking other (non-topicon) templates, but will try to soon:Jay8g [V•T•E] 04:06, 24 August 2014 (UTC)

I tried removing the gadget, but that didn't solve the problem:Jay8g [V•T•E] 19:56, 24 August 2014 (UTC)

This seems to only affect topicons. Other templates making links (like {{stnlink}}) and other images with the link parameter set don't seem to have this problem:Jay8g [V•T•E] 20:12, 24 August 2014 (UTC)

I know that there are problems with "out of skin" templates (things that are typed at one point in the wikitext code but appear in another). However, I can't reproduce this, because in both Safari and Firefox, the "out of skin" icon displays off the (right) edge of the screen. Try editing this version of my sandbox, and let me know if you can see the icon. The {{good article}} template is the only thing on the page. Whatamidoing (WMF) (talk) 23:28, 25 August 2014 (UTC)

I do see the icon. I guess this is a OS/skin issue (Windows 7, Firefox 31, Monobook for me):Jay8g [V•T•E] 16:58, 26 August 2014 (UTC)

Thanks, Jay8g. So if I'm understanding this correctly, this is what you get:

Open page containing {{good article}} in VisualEditor
Click the good article icon/template
VisualEditor exits, and you are reading the page that you had just opened in VisualEditor (and not the WP:GA page that the icon normally links to, right?)

What you want is:

Open page containing {{good article}} in VisualEditor
Click the good article icon/template
Edit the template just like any other.

Is that right? Whatamidoing (WMF) (talk) 23:17, 26 August 2014 (UTC)

Whatamidoing (WMF): Not quite. Clicking the icon takes you to the target of its normal link, so Wikipedia:Good articles for {{Good article}}, Wikipedia:Protection policy#semi for {{pp-vandalism}}, etc, and not the page being edited. Obviously, it should simply select the template, like it does for other templates:Jay8g [V•T•E] 23:36, 26 August 2014 (UTC)

Thank you! It's now T72074. Whatamidoing (WMF) (talk) 00:37, 27 August 2014 (UTC)

Ctrl-RightArrow should move to start of word, not end of word

For consistency with most other software, the keyboard shortcut ctrl-right-arrow should move the insertion point to the start of the next word, not the end of a word as it currently does. (My experience of "most other software" here is on Windows.)

In case it matters, my editing platform is Windows 7, Firefox 30.0, MonoBook skin. Mitch Ames (talk) 01:26, 24 August 2014 (UTC)

For Macs, it's [option] rather than [ctrl]. In Word for Mac, option-right-arrow moves the cursor to the beginning of the next word. In VE (Mac, Firefox, Vector), option-right-arrow moves the cursor to the end of the word. That's also true of the wikitext editor, by the way, at least for me. -- John Broughton (♫♫) 03:31, 24 August 2014 (UTC)

Hi Mitch Ames, and thanks for this suggestion. Would you please try a few ctrl-right-arrow and ctrl-left-arrows in the wikitext editor, and tell me if you get the same behavior in wikitext editor as you do in VisualEditor? I might well be wrong, but I thought that VisualEditor was leaving this particular thing up to your browser. Whatamidoing (WMF) (talk) 23:33, 25 August 2014 (UTC)

I presume by "the wikitext editor" you mean just the default text editing window that is used when "edit source" is clicked .... in which case ctrl-right-arrow moves to start of next word and ctrl-left-arrow moves to start of previous word (which is what I expect, being consistent with much most other software). It's only in Visual Editor that ctrl-right-arrow moves to end of word. Mitch Ames (talk) 12:51, 26 August 2014 (UTC)

Thanks! That's very useful. I'll file it as a bug report later. Whatamidoing (WMF) (talk) 23:18, 26 August 2014 (UTC)

Can you give a brief summary of how such a basic error got past whatever testing is done on VE, and some assurance that such sloppiness is being addressed? Eric Corbett 23:39, 26 August 2014 (UTC)

Well, I don't think I'm going to file a bug report after all. After asking around, this is the intended behavior. "Match what Microsoft does" was apparently not a design goal; all cursoring currently matches the system used by both Linux and Mac boxes. Eventually (maybe sometime in 2015?) the plan is to return cursoring to native browser control, at which point this minor difference will automatically return to whatever the OS's default is. This will mean no visible change for Linux and Mac users, but Microsoft users will starting seeing the behavior that is more common for their OS at that time. If you're interested in tracking this, then it's blocked by a bunch of complex language support issues, so watch for announcements about major improvements to language support (like Chinese). Whatamidoing (WMF) (talk) 00:31, 27 August 2014 (UTC)

It's not resolved at all, just swept under the carpet as usual. Try using LibreOffice running under Linux for instance to see how spurious the Windows argument is. Eric Corbett 01:22, 27 August 2014 (UTC)

No, it's postponed to a time where it is technically more realistic and maintainable. —TheDJ (Not WMF) (talk • contribs) 11:23, 27 August 2014 (UTC)

BTW, for tracking purposes and to prevent multiple reports, it might be useful to file the report anyways. This page is a very bad substitute for a public record. —TheDJ (Not WMF) (talk • contribs) 11:24, 27 August 2014 (UTC)

Color coding the wikitext editor

I have said before, and I still believe, that colour coding would be a massive boon in the text editor. I can't remember now whether it was said to be technically impossible. If it is possible, it should IMO be near or probably at the top of the list. 86.151.119.38 (talk) 00:00, 25 August 2014 (UTC)

Do you mean something that takes nearly illegible paragraphs and marks them up like this?

{{Infobox person |name=Alice Expert{{citation needed|date=July 2013}} |occupation=Expert{{dubious|date=July 2013}} |alma_mater = Wassamatta U|awards = [[Wooden spoon (award)|Wooden spoon]]<ref name=Infobox>{{cite web |url=http://www.example.com |title=Infobox Example Citation |date=February 2014 |author=O'Nymous, Ann}}</ref>}}}} In my real wiki-life, I am User:WhatamIdoing. I've been a regular editor at the English Wikipedia<ref>[http://example.org Example]{{Dead link}}</ref> since 2007, PMID 12345678 ISBN 9781234567890 Parameter error in {{ISBN}}: checksum and I've been in the top 500 most prolific editors of all time for a couple of years. My interests run from [[WP:MED|medicine]] to pastry to education, with odd points in between. I also spend a lot of time working as a [[meta:Metapedianism |metapedian]], which in my case means supporting WikiProjects through the English Wikipedia's [[Wikipedia:WikiProject Council|WikiProject Council]] and helping write policies and guidelines.

There are tools like WP:WikiEd that do this. Whatamidoing (WMF) (talk) 22:35, 25 August 2014 (UTC)

You can also activate a gadget like mw:User:Remember the dot/Syntax highlighter to have syntax highlighting in the wikitext editor, see fr:Utilisateur:NicoV/common.js. --NicoV ^{(Talk on frwiki)} 07:15, 26 August 2014 (UTC)

That one is also available as a Gadget, so just one 'checkmark' away form activating :) —TheDJ (Not WMF) (talk • contribs) 08:35, 26 August 2014 (UTC)

I think these do not work in IE. Also the second one is only available to registered users. I advocate something available to all in all reasonable browsers. (Please do not bother suggesting using another browser. There are reasons why I am not able to.) 109.147.185.246 (talk) 19:36, 29 August 2014 (UTC)

The "beta" word

Hello! On it.wiki we are discussing about the editing labels at the top of the page. We'd like to have the same your setting, or rather having the "Edit" label when VE is off, and "Edit source" and "Edit beta" when VE is on. But on it.wiki VE is enabled by default, so we don't know if our situation is the same of yours. How can we do? --Horcrux92 (talk) 11:33, 30 August 2014 (UTC)

Hello! How about you ask your local community liaison on the it.wp feedback page, to begin with? :D --Elitre (WMF) (talk) 11:35, 30 August 2014 (UTC)

Cause you had already seen the discussion, so I supposed that you didn't know how to fix it (without supposing that you simply did not want to do it). --Horcrux92 (talk) 11:58, 30 August 2014 (UTC)

I wasn't asked anything. Please proceed to do so in the adequate place if you need my help? :) Best, --Elitre (WMF) (talk) 12:00, 30 August 2014 (UTC)

No easy way to find images by name in article.

Tracked in Phabricator
Task T72243

This mainly affects the situation where an image is moved to commons but has to be renamed in process. I can easily get a list of pages that link to the image under the old name. However the visual editor provides no easy way to locate an image already linked by file name. This forces me to search by scrolling through possibly the entire article. As long as raw wiki source access is provided along side the visual editor as it is now this is ok. Phatom87 ^{(talk • contribs)} 00:43, 31 August 2014 (UTC)

Hi Phatom87, in this case you'd be looking for a missing (red link) image, basically? --Elitre (WMF) (talk) 07:40, 31 August 2014 (UTC)

Elitre (WMF) Actually in this case this is before the local copy has been deleted so the link to the old name is still valid. Therefor the image and not its name is shown preventing a search via the browsers search function. Red links already show the file name so this isn't a problem.Phatom87 ^{(talk • contribs)} 00:51, 1 September 2014 (UTC)

There are absolutely no plans to remove the wikitext editor.

It sounds like it would be convenient for you if the name of the image were searchable from your browser's regular search. Your idea is now T72243. It's a new idea, and I've no idea what the team will decide, but I think it might be useful sometimes. Whatamidoing (WMF) (talk) 03:39, 1 September 2014 (UTC)

Phatom87, red image links don't show up while editing, which is why I was asking. A temporary workaround for your workflow, if the number of pictures is relatively small, is hovering or single-clicking on them while VEditing so you can see the file name. HTH, --Elitre (WMF) (talk) 07:55, 1 September 2014 (UTC)

Thanks Elitre (WMF). In this case that was a particle alternative I still used source edit mode for convenience. Just wanted this put out there before the feature becomes final.Phatom87 ^{(talk • contribs)} 02:23, 2 September 2014 (UTC)

Link editor: incorrect "new page"

Testing, random page Media in Erie, Pennsylvania. Try linking the word "digitally" to "Digital". When you click inside "digitally", you get the link help, with all pages starting with "digitally". I don't want this, so I change the word at the top to "digital" instead. I get "New page: digital" (in red), even though we obviously have a page called digital. Changing "digital" to "Digital" doesn't help. Fram (talk) 12:11, 2 September 2014 (UTC)

I believe this is because the search system isn't perfect. Proposed solution, let's not use it in some cases. --Elitre (WMF) (talk) 12:40, 2 September 2014 (UTC)

Longer drop-downs don't work

Tracked in Phabricator
Task T72218

When you get a drop-down with suggestions, e.g. when linking, you get a scroll-bar at the right side of there are too many choices. It is impossible to click this bar (or the button at the bottom of it), trying to do this closes the window. Fram (talk) 12:13, 2 September 2014 (UTC)

I reported it about 10 days ago, but it was ignored. --NicoV ^{(Talk on frwiki)} 12:19, 2 September 2014 (UTC)

Looks like it was reported, though. (I don't think I get scrollbars when making a link. Can you?) --Elitre (WMF) (talk) 12:51, 2 September 2014 (UTC)

Yes, just create a link near the bottom of what is displayed or scroll after the inspector being displayed. --NicoV ^{(Talk on frwiki)} 13:11, 2 September 2014 (UTC)

Uhm... I'm trying to change the Egypt link in my sandbox or to add a link to the word Welcome. In both cases, no matter what I type, I'm presented with a short list of suggestions. No scrollbars in sight. --Elitre (WMF) (talk) 13:16, 2 September 2014 (UTC)

Elitre (WMF), try now after I've added some vertical spacing. I couldn't reproduce it with your existing version, but now it's easy to have it happening. --NicoV ^{(Talk on frwiki)} 13:26, 2 September 2014 (UTC)

Make sure that when you add or change the link, the word "Egypt" is near the bottom of your screen. The dropdown always goes down (perhaps another bug), so if starts from near the bottom of your screen, it is much smaller, and the rest should be accessible through the scrollbar. This bug is especially important for people with smaller screens, like mobile users, so with that in mind you can give it the lowest priority :-D Fram (talk) 13:28, 2 September 2014 (UTC)

Ok. I don't think the Bugzilla report needs to be changed, thanks for showing this to me. --Elitre (WMF) (talk) 14:26, 2 September 2014 (UTC)

Various problems

I have just been editing a long list of articles with links to Millennium Project to change them to The Millennium Project. A number of issues came up detracting from doing this efficiently.

The screen scrolling around when a section edit link is hit is very distracting. I have already found the place I want to edit, moving the screen around is only liable to make me lose my place. If I have to search for the insertion point text again, I may as well have used the source editor. This happens on all section edits, but is a particular problem on the lede section which seems to get reinterpreted as a request to edit the first subsection. Scrolling to the section heading is useful if one has arrived via a url, but I suggest that is an uncommon way to start editing and if one has initiated editing "on-screen" then there should be no scrolling. Scrolling to the top of the section (or top of the article if more than one section has been edited) makes sense on save, but not on intitiating editing.
Sometimes the link dialogue would correctly identify The Millennium Project as a redirect, and sometimes it would show it as a redlink proper page. I couldn't work out what the difference was in the two cases, it just seemed inconsistent.
I think this has been reported before (not sure) but I just want to emphasise that having to type the same edit summary over and over again is a MAJOR PAIN IN THE ARSE.
VisEd refused to edit some links in see also sections, I think because some kind of columning template was in use.

This task, numerous repetitions of the same simple edit, should have been a showcase for the improved efficiency of WYSIWYG editing. I am very disappointed that it was not. SpinningSpark 13:56, 27 August 2014 (UTC)

Thanks for these comments:

Local gadgets (section edit link on the lead) are not supported by VisualEditor (or any other part of Wikipedia's software, except by happy accident). However, when VisualEditor opens, it should take you back to the same place you're in. It does move—which is annoying—because the table of contents disappears, but it's supposed to move back to the original place. This is cancelled if you start scrolling before it is completely finished opening, and it also doesn't cope well if there is collapsed content.
Timing. Sometimes Search is slower at providing any response at all.
I believe that the level of agreement here is 100%. There are several bugs, including some enhancements that will provide custom automatic summaries (including one that ought to work beautifully for exactly this sort of edit). But not this quarter. :-(
I haven't seen column templates that can't be edited yet, but you do have to open them in the complex transclusion tool, which is Not Exactly Intuitive. Whatamidoing (WMF) (talk) 16:16, 27 August 2014 (UTC)

I don't agree that VE scrolls back to the original place. It scrolls (in two jumps, presumably the ToC issue) to the top of the section of the clicked link. This can be a long way from where one had focus on launching VE. By the way, is there a short-cut key for launching VE? On the lede section, if VE does not support editing the lede section then there should not be an edit link for VE in the lede section. Having it there is counterproductive if it does not actually do anything useful. SpinningSpark 17:43, 27 August 2014 (UTC)

The question is officially whether the gadget properly supports VisualEditor, not the other way around. The link works, in the sense that it opens the page for editing using VisualEditor. However, it provides an incorrect edit summary (for the first section, not for the lead).

The shortcut is "v": control+⌥ Option+v on a Mac, and control+alt+v on others. You can see this in the tooltip if you hover over the tab for editing.

I've just tested the scrolling at Juan_R._Torruella#Sailing_career (from Special:Random). Clicking the edit-beta button there does open the page at that section for me. Does it do something different for you? Whatamidoing (WMF) (talk) 18:52, 27 August 2014 (UTC)

A couple of comments on the above.

Re the gadget: it's true that the gadget currently needs to be changed - it gives the same link for the edit beta link in the lead as it does for the first section, which makes no sense no matter what one thinks the resulting behaviour should be. I tried manually editing the link to point to vesection=0 to see if that would work, but VE gives an error message; evidently that's not supported. That sort of makes sense, given that all section editing does in VE (at the moment, anyway) is scroll you to a certain point and preset an edit summary. I suppose the best fix would be to have the gadget changed so that instead of vesection=1 it should just say veaction=edit, without the vesection parameter.
Re autoscrolling on section edit: is the ToC issue going to be fixed? That is, will the screen at some future point only jump once? Presumably this would be best done by displaying the ToC instead of hiding it, but even if not I think the double jump is a display bug.
I can't get the Mac keystrokes to work on my iPad -- is there a different sequence for iPads? I tried with both Safari and Chrome.
When the keystroke sequence works, does it leave the screen in the same position or does it scroll it anywhere? I agree with SpinningSpark that the right behaviour would be to leave the user looking at the exact same screen they were looking at when they invoked VE. Mike Christie (talk - contribs - library) 21:22, 27 August 2014 (UTC)

My wife has her Mac with her (10.9.4 OSX) and she tried Ctrl-Option-V in both Chrome and Safari, with no effect. Any idea what we could be doing wrong? Mike Christie (talk - contribs - library) 21:50, 27 August 2014 (UTC)

Using the buggy Visual Editor? Eric Corbett 21:57, 27 August 2014 (UTC)

It is buggy. I guess a career working in computing has made me more easygoing about working with software with bugs in it; though I know it doesn't have that effect on everyone in the business. I've been using VE for almost all my content edits for quite some time now, and find it much pleasanter than the wikitext editor. I think it's probably because the things VE seems to be worst at are mostly things that power users are going to want: complex templates, tables, nested templates, complex syntax. The things I spend most of my time on -- straightforward text editing, plus some referencing and simple formatting -- work pretty well in VE. Mike Christie (talk - contribs - library) 22:35, 27 August 2014 (UTC)

Ctrl-Alt-V does not seem to be right, at least in Windows 7. After a bit of experimentation I found that the correct keystrokes are: in Firefox, Alt-Shift-V; in Chrome, either of Alt-Shift-V or Alt-V; in Internet Explorer, can't find anything that works at all. SpinningSpark 22:44, 27 August 2014 (UTC)

IE isn't supported yet so I would assume that's why there's no shortcut there. Mike Christie (talk - contribs - library) 22:48, 27 August 2014 (UTC)

IE support will appear in about two weeks. I believe that only IE11 will be supported in the first round. Whatamidoing (WMF) (talk) 03:34, 1 September 2014 (UTC)

Much of the simple stuff works reasonably well now, I agree Mike, but there are still fundamental problems such as pop-up dialog boxes that can't be moved to allow you to see what's behind them. I'd love to know how much has been spent on this crock, and how much more will need to be spent before it's actually ready to be deployed. Eric Corbett 23:10, 27 August 2014 (UTC)

I gave up on V/E about 18 months ago when I learned there was no point trying to run it on my old PC. Apparently V/E was written on and for state of the art PCs and state of the Ark PCs like mine ran it ridiculously slowly, I could do far more edits per hour on the classic editor than using V/E. At the time that was a "Won't fix", all this stuff about being a global movement not just for the western technoscenti doesn't apply to our IT development. Is that still the case, is it that the simple stuff works reasonably well provided you have fairly new kit, or have they now rewritten it to support old PCs provided they are on modern browsers? If so the day when V/E becomes a net positive may not be that far away. Ϣere SpielChequers 13:12, 28 August 2014 (UTC)

Hi WSC, performance has improved significantly during the last year or so. However, the difference between faster and fast enough is individual, and I wouldn't want to guess where you'd fall on that scale. For large, image-heavy articles, it's going to be faster to use the old editor, probably for the next few years. (It's also faster to open those articles in the old editor than to load those pages for reading, sometimes by more than a factor of five.) I encourage you to try it out on a couple of small articles and let me know what you think. Whatamidoing (WMF) (talk) 03:34, 1 September 2014 (UTC)

@WhatamIdoing: I've now tried Alt-Shift-V in Chrome and it doesn't seem to have behaviour consistent with the section editing (which works correctly for me, in that it leaves the section I clicked "edit beta" on at the top of the screen). Alt-Shift-V doesn't leave the screen as it was when I press those keys; it scrolls it slightly -- about half a page when I tried it. What's the intended screen display position if Alt-Shift-V is pressed? Mike Christie (talk - contribs - library) 02:28, 29 August 2014 (UTC)

In Firefox, it scrolls to the top of the page. No idea if that is the intended behaviour or not, but in my opinion, it should not scroll at all. What makes the software think it knows where the user wants focus better than the user? SpinningSpark 19:51, 29 August 2014 (UTC)

There's one thing that might imply a little scrolling: the VE toolbar that appears at the top of the screen obscures some text, so it might be natural to scroll the screen so that whatever was top of page is now the first visible text below the toolbar. That might be more intuitive than simply leaving the text in the exact position it was in when the user pressed Alt-Shift-V. Mike Christie (talk - contribs - library) 20:18, 29 August 2014 (UTC)

In Safari, it scrolls (up) an amount equal to the length of the table of contents. In Firefox, it takes me to the top of the page. I don't remember what the intended behavior is, but I'm willing to bet that it's supposed to be the same in all browsers. I'll talk to James F on Tuesday, and I'll ask him then. Whatamidoing (WMF) (talk) 03:34, 1 September 2014 (UTC)

@Whatamidoing (WMF): any word on this? Mike Christie (talk - contribs - library) 11:53, 3 September 2014 (UTC)

Hi Mike,

The intended behavior is no movement at all (or almost none, since the addition of a slug nearby might cause some movement even once the table of contents is in place). However, there are some known bugs that causes the odd scrolling that you're seeing. It sounds like every browser is going to have to be fixed separately, and in the case of IE, it's possible that each version of the browser will have to be fixed separately. Whatamidoing (WMF) (talk) 23:09, 3 September 2014 (UTC)

OK, thanks -- I'm glad to hear that that's the plan; as SpinningSpark says, it wouldn't make sense for the browser to think it knows better than the user. Mike Christie (talk - contribs - library) 23:14, 3 September 2014 (UTC)

Edit summary bug fixed in edittop

The gadget that adds [edit] and [edit beta] links to the top of the lead did not work properly with VE: the [edit beta] link was actually set up to edit the first section, not the lead, with the result that on saving in VE there would be a default edit summary including the first section. This has now been fixed by TheDJ. Mike Christie (talk - contribs - library) 10:06, 3 September 2014 (UTC)

Many thanks to User:TheDJ for fixing the gadget. Whatamidoing (WMF) (talk) 23:25, 3 September 2014 (UTC)

DEFAULTSORT and categories moved + other problems

Tracked in Phabricator
Task T72373

Hi, see this edit, where the categories were moved by VE. Maybe related to the end of the table missing. --NicoV ^{(Talk on frwiki)} 18:44, 2 September 2014 (UTC)

I've been unable to reproduce this, so it may not be related to the broken wikitext in the table. Whatamidoing (WMF) (talk) 00:19, 4 September 2014 (UTC)

Categories split in two places, with some in double

Tracked in Phabricator
Task T56169

Hi, in this edit, VE split the categories in two different parts. Some of them appear in two parts: Comte de Carcassone and Décès en 812. In addition, VE added an empty title (== ==) between the two sets of categories. --NicoV ^{(Talk on frwiki)} 21:09, 3 September 2014 (UTC)

And also a problem with the handling of <sup>...</sup> tags, with one put around a single space character. --NicoV ^{(Talk on frwiki)} 21:12, 3 September 2014 (UTC)

Sometimes, I wish that I could have a video of what the user did.

The superscript tags are working as designed. It's not the most elegant approach, but if you select a space and apply superscript, then you get sup tags. In this case, the user appears to have selected a couple of letters (in a link) plus the space (not part of the link), and so won two pairs of sup tags. (Link formatting is all contained within the link; therefore you get [[Example|'''bold''']]'''er''' rather than '''[[Example|bold]]er''', which is what I'd choose in wikitext.

The stray == == was probably due to the user setting the formatting and not removing it (switching it back to paragraph). I can't think of any good reason to have an empty section heading, so I've requested that it be removed in T72368. If anyone's got a good reason not to automatically strip this out, then please either comment at the bug or let me know.

These category problems sound familiar. I'm going to spend a while searching through the list of potentially undead bugs. Whatamidoing (WMF) (talk) 23:39, 3 September 2014 (UTC)

For the sup tag, there's a comma between the two sets of sup tags, so the explanation is not so simple. Well, yes, probably the user selected also the space, but, as I repeated many times, the problem is that in VE the user doesn't see that he has applied silly formatting over a space character. Every day, I find dozens of articles that have been formatted so badly that it's a pain to fix them to have a correct formatting (it's not only sup tags, but all formatting like italics or bold which tend to take extra spaces, extra punctuation, ...). When will the VE team look at what is daily produced on articles with VE to fix it so we don't have so many articles to rework ? --NicoV ^{(Talk on frwiki)} 21:40, 4 September 2014 (UTC) Edit: an example of fixes we have to apply on a daily basis.

How would you expect a visual-oriented editor like Google Docs or Microsoft Word show someone that they had applied a superscript setting to a space?

I don't think that there is anything we can do to prevent people from italicizing punctuation. While the MOS here opposes it, most (but not all) formal style guides support it. The correct answer probably varies by language. Whatamidoing (WMF) (talk) 23:16, 4 September 2014 (UTC)

I don't think it's a bug that VE formats what people ask it to format, and I agree that visual editors don't give any indication when (for example) a space is italicized, so there's no reason for VE to do so. Since the wikitext editor is not going away, though, I think there's an extra design constraint on VE to convert visual formatting into wikitext as far as possible in the same way a human editor would have written it. I'd regard it as an enhancement, not a bug, but it's definitely desirable. In this case that would mean recognizing that a formatted span of characters that ends in a space doesn't need to have the space formatted.

I think it might be quite difficult to achieve this, though. Taking NicoV's example: if you had [[Example|'''bold''']]'''er ''', what should VE do at the moment you press Ctrl-B to bold that text? Convert it to '''[[Example|bold]]er ''' internally? If VE takes out the space from the italics immediately, then the user won't get italics when they place the cursor after the space and start typing. That's a behavioural change, not just a wikitext change. Is that OK? Mike Christie (talk - contribs - library) 23:50, 4 September 2014 (UTC)

I wouldn't mind having '''[[Example|bolder]]''' which is a lot cleaner ;-) In WPCleaner, I never suggest replacements like [[Example|bold]]er, the tool does the extra step of compacting the link so that you don't have both a "|" and text after the "]]" at the same time.

If you put the cursor just before a word (so, just after a space character), click on Italics, and start typing, the new text is in italics ; so VE is already capable of memorizing the fact that italics was requested but not already applied to the wikitext. It's probably not so easy to develop, but currently the resulting wikitext is so ugly that it requires a lot of work to fix it every day. Honestly, I do believe that producing clean wikitext is a "must", and not just a "would be nice" feature. This includes bold, italics, ... but also nowiki tags (like for the single quotes), titles, paragraphs, .... --NicoV ^{(Talk on frwiki)} 13:17, 5 September 2014 (UTC)

Status of copying tables

Tracked in Phabricator
Task T72375

What's the status of copying tables? I just tried cutting and pasting a table; it seemed to work but then when I tried to save the page VE froze. If this is supposed to be working I can post a note on reproducing it -- I tried it twice and got the same result each time. Mike Christie (talk - contribs - library) 02:37, 25 August 2014 (UTC)

Mike Christie, what was the source?

I've successfully copied and pasted tables from other websites and spreadsheets, but I don't think I've tried to copy a table from another Wikipedia page. Whatamidoing (WMF) (talk) 23:19, 25 August 2014 (UTC)

The article was Tales of Wonder (magazine); I'm traveling at the moment and only have an iPad with me, and I can't reproduce the problem with the iPad, but I can tell you what I was trying to do. I selected the table from first to last cell, pressed Ctrl-X (or maybe Ctrl-C -- I don't recall for sure), then clicked in another section and pressed Ctrl-V. The table appeared with slightly different formatting, and from that point on the Save page button had no effect. Mike Christie (talk - contribs - library) 03:11, 27 August 2014 (UTC)

It works for me at the moment, in Safari and Firefox on my Mac, but that doesn't mean much. Some sorts of table editing are very unstable. I also found it difficult, if not impossible, to select the entire table, without leaving any of it behind when I cut it. It does reformat the table from single line into multiline formatting (turning "! column !! column !! column" into three separate lines), which might be the source of the appearance change... or might not. Do I recall correctly that you're running Chrome and Windows 7? Whatamidoing (WMF) (talk) 05:20, 27 August 2014 (UTC)

Yes, Chrome and Windows 7. When I get back home I'll post some screenshots showing what happens when I try it. Mike Christie (talk - contribs - library) 21:24, 27 August 2014 (UTC)

OK, this is what the table looks like when I hit Ctrl-X or Ctrl-C, and this is what the screen looks like after I paste it at the top of the previous section. If I do this with Ctrl-C and then Ctrl-V, it will save; if I use Ctrl-X instead, it doesn't save the article -- the Save Page button becomes unresponsive. Mike Christie (talk - contribs - library) 22:33, 29 August 2014 (UTC)

@Whatamidoing (WMF): is this something that needs to be entered as a bug? Mike Christie (talk - contribs - library) 23:53, 3 September 2014 (UTC)

Or maybe two (one for formatting loss and one for not being able to save). I've been mulling this one over, but I think I'm going to file it as one, and then they can split it if they want to.

Would you mind trying something for me? Open the page and select the whole table, plus some text before and after it (you might need to add some text to do this). Then copy and paste, and see if you get the same problem. Whatamidoing (WMF) (talk) 00:38, 4 September 2014 (UTC)

Also, Mike Christie, this may sound paranoid, but would you please confirm that you can safely cut (Ctrl-X) plain text, without the Save button breaking? There were some changes made to that behavior just the other day. Whatamidoing (WMF) (talk) 00:51, 4 September 2014 (UTC)

Interesting. When I do that, the cut and paste works perfectly, the formatting appears unchanged, and the save button is active. However, the actual saved version doesn't have the same formatting as the pasted table -- see this version for what the result looked like. And yes, I can still cut and paste ordinary text. Mike Christie (talk - contribs - library) 00:53, 4 September 2014 (UTC)

Some further investigation reveals that switching to source code editing hangs after the cut and paste as well.

I think what must be happening is that because I can't select the whole table, I am only cutting and pasting cells, not the table. That means that the formatting at the table level is lost, which explains the appearance of the pasted cells in the screen shot. It doesn't explain the appearance of the successfully pasted entire table in the version linked just above, since in that case I did select the whole table. A couple of thoughts: (a) the UI has to make it clear to the user (perhaps by the way the highlight looks, just as Word does) that they have selected cells and not the whole table. The current highlight pattern does do this, so I don't think any change is needed. (b) if you copy cells from within a table, and paste them somewhere, what should happen? I think the table level formatting should be retained. If the cells are pasted into another table then it should probably not carry over table formatting (though I could see a future for variant pastes, such as the "paste special" options MS Word and Excel provide). Mike Christie (talk - contribs - library) 01:15, 4 September 2014 (UTC)

I'll add this to the bug report. Do you happen to know whether VisualEditor reaches its refuse-to-save state after the 'cut', but before the 'paste'? Can you keep editing afterwards? I've been assuming that it's the paste that's the problem. Whatamidoing (WMF) (talk) 23:59, 4 September 2014 (UTC)

It turns out it's the cut; I repeated the experiment a couple of times to be sure. I also was unable to reproduce the problem with switch-to-source failing; it worked several times in a row just now. And yes, I can keep editing afterwards; I only know there's something wrong when I try to save. So long as switch-to-source is working this isn't a disaster, just an annoyance. Mike Christie (talk - contribs - library) 00:08, 5 September 2014 (UTC)

That might be a disaster for people who don't know how to do that, but I'm glad you've found a reasonably reliable workaround. I'll hassle the devs about this. Thanks for all the details. Whatamidoing (WMF) (talk) 17:07, 5 September 2014 (UTC)

nowiki and damaged internal links

Tracked in Phabricator
Task T72286

Hi,

When will internal links be correctly handled by VE to prevent things like that: [[B.A.P]] [[Super Junior|<nowiki/>]][[B.A.P|Super]] Junior. To reproduce this:

Edit Boys band on frwiki
In the history chapter, 4th paragraph, put the cursor before the S of the link to Super Junior
Click on link icon in the toolbar
Copy the URL https://fr.wikipedia.org/wiki/B.A.P in the link inspector and click Terminé
When previewing modifications, you can see that it has been replaced by [[B.A.P]] [[Super Junior|<nowiki/>]][[B.A.P|Super]] Junior which shows several problems: there's a link without text displayed, the existing link has been cut in two
And also, what is displayed in VE doesn't match at all what the result will be when saved:
- "Super" is displayed as an external link, but in the modifications preview, you see it's an internal link
- If you hover over "Super", both "Super" and "Junior" get underlined, but in the modifications preview, "Junior" is not inside the link
- "Junior" is displayed as an internal link, but in the modifications preview, you see it's now just text
- If you hover over "Junior", both "Super" and "Junior" get underlined, but in the modifications preview, "Junior" is not inside a link

--NicoV ^{(Talk on frwiki)} 09:21, 2 September 2014 (UTC)

Tested, got the same result (in preview, haven't saved). Uh, that is one ugly link you get... You can get the same behaviour elsewhere as well, e.g. (random page) go to Naive John, VE editing, third paragraph of the Art section, and put the cursor in front of "Flemish". Link to "Early Netherlandish painting", preview, wince. Or, basically, try it with any link you like; go to the start of an existing wikilink, open the link editor, type and choose whatever you like, and look at the result. Not good! Fram (talk) 09:35, 2 September 2014 (UTC)

Hi, what is the result you are trying to achieve with a similar edit? --Elitre (WMF) (talk) 10:44, 2 September 2014 (UTC)

The idea was just to change the target of an internal link: open the link inspector and change the target, that's one of the most basic feature of wiki editing. My attempts were made to try to understand how this modification was done. --NicoV ^{(Talk on frwiki)} 10:59, 2 September 2014 (UTC) Edit: basically, I was just following the user guide, chapter "To change or remove an existing link", just having my cursor just before the first character. --NicoV ^{(Talk on frwiki)} 11:08, 2 September 2014 (UTC)

Yes, while the initial report (with an external link) may not be the most common, the subsequent tests show clearly that this applies to any wikilink you try to change (e.g. after a warning from DabBot). Changing the target of a wikilink should be basic, easy stuff. However, it goes consistently wrong (never mind the difficulties the link tool has recognising existing pages, I often get a "New page" red link addition in the tool when the target does really exist exactly like that). Fram (talk) 11:16, 2 September 2014 (UTC)

To change or remove an existing link, click anywhere within the linked text, I think that's why it wouldn't work otherwise? A "saner", easier way to change target and label is being requested here, I'd really appreciate to gather ideas as to how this could be done. --Elitre (WMF) (talk) 11:20, 2 September 2014 (UTC)

Yes, probably, but since Ctrl+K or clicking the button opens the link inspector even when the cursor is just before the first character of link, it should work correctly in this case. Concerning bugzilla 53973, I find the solution with two fields (one for the link, one for the label) fine, it's simple, very understandable, ... At least, it would be a lot better than the current situation which still results in many damaged links (nowiki, incorrect target, split links, extra space characters included, ...) What did James mean by saying that it would make the user experience too heavy ? --NicoV ^{(Talk on frwiki)} 11:37, 2 September 2014 (UTC)

@Jdforrester (WMF): When you want to have a link that is the same as the displayed text, having two fields is too much. Of course, this ignores that it is now very user-unfriendly inVE when you want to have a display that is different from the linked text, and it also ignores that the current user experience is way too heavy as well. Fram (talk) 12:08, 2 September 2014 (UTC)

(ec)So, it seems like whoever wrote this was aware of the problem, and "fixed" it by putting this in the user guide? Fram (talk) 11:42, 2 September 2014 (UTC)

By the way, looking at the user guide, it is again very seriously outdated. Fram (talk) 11:48, 2 September 2014 (UTC)

The user guide was updated on Mediawiki.org earlier this month, largely thanks to User:John Broughton, and a good deal of it was translated at Wikimania.

John, I've got news: subst'ing is working again, so I restored that section of the user guide. I can make new screenshots for it if you'd like, but all the screenshots will need to be re-done again in a few weeks anyway (planned changes are almost all aesthetic, like new colors for the buttons), so I'm inclined to put it off until then, unless you'd like it sooner. Whatamidoing (WMF) (talk) 23:16, 3 September 2014 (UTC)

NicoV, I believe this was discussed in several bugs, I don't recall details (this might have to do with several reasons, technical ones, user expectations...). I like Google Docs' approach to this, and have just said so in the bug. Fram, the emphasis was mine: that sentence still means that if you want to change a link you need to act on it, not somewhere around :) As for the user guide, I think the one on mediawiki is ok. Just copy/pasting it here might be enough. --Elitre (WMF) (talk) 11:51, 2 September 2014 (UTC)

Elitre, I hope you agree that this is a serious bug? Text-only is not always good to communicate, so it's not clear to me if you believe that "it isn't wrong, you just have to clic inside the bluelink" is sufficient as an answer, or if it was a jokey reply without the neaning that this problem isn't really a bug. Fram (talk) 11:57, 2 September 2014 (UTC)

I have added this here. Regards. --Elitre (WMF) (talk) 12:29, 2 September 2014 (UTC)

@Fram: I suspect you're referring to the VE User Guide at wiki.riteme.site. As Whatamidoing noted, I helped update the VE User Guide at wikimedia.org, which is a different document. Nor is there any automated way (that I know of, anyway) of making the two guides the same, since the guide at mediawiki is designed to be translated (with lots of related markup) and the en.wikimedia.org guide is not. And I just don't have the time or energy to update both. -- John Broughton (♫♫) 23:55, 3 September 2014 (UTC)

Nothing automated. There is a way to extract the non-translate-markup-ed version from Mediawiki, but it's remarkably non-intuitive. Unless you'd object to having the local one over-written, then I'll see if I can figure it out again. Whatamidoing (WMF) (talk) 00:34, 4 September 2014 (UTC)

@Whatamidoing (WMF): I'd like to see the local guide overwritten. If someone has a problem with that, they can always revert. Or, alternatively, copy whatever they want from a prior version into the newest version. (I know the local guide has more guidance about some things, because I wrote that. But it may well have been overtaken by events, so I think it's best to start with a guide that is up-to-date.) -- John Broughton (♫♫) 03:23, 5 September 2014 (UTC)

John Broughton, I've finally extracted it from the clutches of the translation system (entirely thanks to the intervention of translation guru Guillaume), but there's a new problem: the system for producing bot-updated screenshots is over-writing file names. I've added the text and self-reverted, but we're going to have to figure out whether to manually add the file names or to port the image-updating system over here. That's a task for next week, I think. Whatamidoing (WMF) (talk) 17:50, 5 September 2014 (UTC)

Quotes added to otherwise unmodified references

Hi, when I do any modification in Loup (fleuve), when I check the modifications done by VE, I see that 3 <ref>...</ref> have been modified with the addition of quotes around the reference name. VE shouldn't modify articles in parts that are not modified by the user. --NicoV ^{(Talk on frwiki)} 08:11, 4 September 2014 (UTC)

That is a technical change. You don't need quotes around the reference name if the name meets the rules listed at {{refname rules}} since Sanitizer.php checks the refname and adds quotes to the rendered HTML if they are missing. If the name does not meet the rules, then sanitizer.php will incorrectly add the quotes and the refname will be broken. Thus, adding quotes makes the refname more safe. -- Gadget850^talk 15:18, 4 September 2014 (UTC)

I understand that, but I still don't think VE should do this. First, VE has still a lot of bugs that damage articles, so adding extra modifications to the ones done by the user makes checking the modifications more difficult. Second, VE main target is mainly new comers, so how can they understand the modifications if they look at the "Review your modifications" ? So in my opinion, even if this may be useful, this should be done by bots, but clearly not by VE. --NicoV ^{(Talk on frwiki)} 16:34, 4 September 2014 (UTC)

Plus, this issue was raised month ago (here and at Bugzilla), and then it was said and agreed that VE should not do this, and that it was fixed and VE would no longer do it. It seems to be rather hard to get VE fixes to stick though (haven't the snowflakes reappeared as well?). Fram (talk) 20:12, 4 September 2014 (UTC)

I was aware that the snowmen were coming back, I didn't know about the snowflakes... Summer is almost over... --NicoV ^{(Talk on frwiki)} 21:30, 4 September 2014 (UTC)

The 'snowflake' is actually a sun. There are pawns (♙) for text formatting (including links), snowmen (☃) for mostly lanugare-related ContentEditable problems, and weather pieces (black cloud ☁ and sun ☀) for copying and pasting problems.

Nico, do you have the right link there? Quotation marks were added to the name in ref 3 ("roman-") a year and a half ago, in the wikitext editor, when the citation was originally added to the article. Whatamidoing (WMF) (talk) 23:46, 4 September 2014 (UTC)

Whatamidoing (WMF), the link I provided is only to launch VE on the page, I didn't save any modifications to the article, so you won't find the problem in the history. I don't reproduce this behavior right now with Chrome. Yesterday, it was happening with FF, I will check again later. --NicoV ^{(Talk on frwiki)} 04:55, 5 September 2014 (UTC)

I can't reproduce it today, even with FF. I don't know what happened... --NicoV ^{(Talk on frwiki)} 06:52, 5 September 2014 (UTC)

Oh, I misunderstood your comment. I had thought you meant that ref #3, not three different copies of refs #1 and #2, had been changed. Since ref #3 already had quotation marks, that wouldn't have been possible.

It may have been fixed in yesterday's update, which I believe happened in between your editing and my attempt to reproduce it. Whatamidoing (WMF) (talk) 17:15, 5 September 2014 (UTC)

This is T57461 and at this stage, it should only show up when there are cache misses for the Parsoid HTML of the page (should be rare), and hence is not always reproducible. SSastry (WMF) (talk) 05:28, 7 September 2014 (UTC)

Take highlight off citation after insertion

Tracked in Phabricator
Task T72573

T71711 requests that after inserting a link it should not be highlit, so that the user can continue typing without overwriting it. I think the same enhancement would be good for inserting citations. If you select Cite -> Basic, enter a cite, and hit enter, the citation is highlit, so you have to right-arrow to allow insertion of another citation. Mike Christie (talk - contribs - library) 02:20, 7 September 2014 (UTC)

This is an excellent idea. Thank you. Whatamidoing (WMF) (talk) 19:42, 8 September 2014 (UTC)

Any chance of getting my edits back?

I've got VE's "Save Page" button up, but when I click on it, nothing happens. I've just made a lot of edits in a long article ... has this happened to anyone else, and is there anything I can do to save my edits? - Dank (push to talk) 03:06, 9 September 2014 (UTC)

You can try "switch to source", which has saved a long session for me at least once: click on the icon with three lines on it to find it. Mike Christie (talk - contribs - library) 03:23, 9 September 2014 (UTC)

That icon and all the others I tried were unresponsive. I gave up trying and left the page. Unwatching. - Dank (push to talk) 03:36, 9 September 2014 (UTC)

Dank, I'm sorry to hear you lost your changes. I have filed a bug about the Save button earlier today, but I don't know if this is the issue you're experiencing. Should you have other issues in the future though, just know you can switch to source also simply by clicking on the "Edit source" tab. Best, --Elitre (WMF) (talk) 10:13, 9 September 2014 (UTC)

FYI, there has been some discussion on storing 'drafts' on the client side, so that you could recover your changes after such a 'fatal Javascript problem' (or a crashing or accidentally closed down browser). I've actually been tinkering with the same thing for the WikiEditor. It's not on the roadmap of VE or anything just this minute, but it's on the radar and could be something to implement to safeguard against problems like these. —TheDJ (talk • contribs) 11:39, 9 September 2014 (UTC)

Yup, thanks for your note, TheDJ. My crystal ball can see it coming sooner rather than later... --Elitre (WMF) (talk) 13:52, 9 September 2014 (UTC) PS: just for the record, a link to James' explanation of the challenges behind this effort. --Elitre (WMF) (talk) 08:38, 29 September 2014 (UTC)

Dank, I'm sorry you got hit by a lost-work bug. Did you do anything that you would consider unusual (compared to the things you normally do when editing)? Mike's last one, for example, involved cutting a table to move it to another place in the article.

Did you try to copy the article text after it crashed? You said that the buttons were all non-responsive, but I'd like to know whether you were able to select and copy text. Whatamidoing (WMF) (talk) 17:29, 11 September 2014 (UTC)

Thanks. Everything seemed to be working normally, I could cut and paste, and the VE icons gave the appearance of being pressed when clicked, but they did nothing. I didn't think of trying the "edit source" tab. - Dank (push to talk) 17:52, 11 September 2014 (UTC)

Also, does T54640 sound like it describes your experience? Whatamidoing (WMF) (talk) 17:53, 11 September 2014 (UTC)

"Something went wrong" but edit was saved

Tracked in Phabricator
Task T72726

Twice this evening while making minor edits to 2002 Pacific typhoon season I got the message "Something went wrong", and it appeared the save had failed. Checking the article history made it apparent that the save had worked in both cases. The diffs are [2] and [3]. There was another minor edit between these two which saved with no errors. Mike Christie (talk - contribs - library) 01:39, 10 September 2014 (UTC)

Those minor text changes shouldn't cause any problems. I believe (but will need to check) that this is actually a sign of something being unhappy or too slow on the server side. Whatamidoing (WMF) (talk) 17:32, 11 September 2014 (UTC)

Update: They say that it's possible that it's a problem server side, but they can't reproduce it reliably, so they're not sure. "Insanely irritating" and "really bad for users" were the polite words used to describe the problem. If you ever figure out a reliable method of reproducing this, then please share the details. In the meantime, I've filed this as T72726 to make sure that it gets new eyes on it, but it may end up merged into an older bug report. Whatamidoing (WMF) (talk) 17:54, 11 September 2014 (UTC)

Highlight disambiguation links and show all options on the disambiguation page for fixing them.

Tracked in Phabricator
Task T72738

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	When using VE, disambiguation links should be highlighted for easy finding and fixing, and should give all options on the disambiguation page (for example, a link to Spanish should give the option of making the link point to Spain, which is frequently the correct link).
Steps to Reproduce:	I tried fixing disambiguation links in VE, and was disappointed that my Jscript highlighting of dab links doesn't follow through, so if there are several on the page I have to go back and find them all.
Results:	As above.
Expectations:	I expected that link fixes being offered would include likely solutions reflected on the disambig page.
Page where the issue occurs	English Wikipedia
Web browser	doesn't matter
Operating system	doesn't matter
Skin	doesn't matter
Notes:	none
Workaround or suggested solution	n/a

bd2412 T 22:50, 5 September 2014 (UTC)

I believe that this is possible now, but you'd have to write the script to recognize the links.

bd2412, did you write this script yourself? I might be able to find the information you'd need to update it. Whatamidoing (WMF) (talk) 19:43, 8 September 2014 (UTC)

This script is from my ingenious friend User:Anomie. bd2412 T 19:58, 8 September 2014 (UTC)

I think we can safely say that there's nothing that I can tell Anomie about this that he doesn't know or couldn't find out faster than I could. ;-) Whatamidoing (WMF) (talk) 01:08, 9 September 2014 (UTC)

Actually, to be clear, I am not seeking to fix this just for my own use. I would like VE to highlight disambiguation links for all editors, whenever it is used. That will make it easier for anyone who is looking for such links to find and fix them. Can Anomie's script be incorporated into VE to that end? bd2412 T 18:30, 11 September 2014 (UTC)

Thanks for the clarification. It's been requested before as a feature for the link inspector, but I couldn't find one for doing this everywhere. I've added it as bug 70738. Whatamidoing (WMF) (talk) 19:25, 11 September 2014 (UTC)

If I can add my 2c on this...I think I like the idea of coloring the disambiguation links with another color. I know that at the drop down menu it makes clear if a page is a disambiguation but it happens many times when you type too fast you'll miss that and add it without noticing. But an editor sure won't miss the different color. I read the bug (I can't comment there that's why I am doing it here) and even if I agree that the editor might be confused if they don't know what the color means but I am sure curiosity will make them click on it (I would!) to see what is happening and they'll see that it's because is a disambiguation page. If the color can be added on VE in general I believe it would be really useful! Thanks for reporting this issue BD2412 :) TeamGale 21:43, 11 September 2014 (UTC)

There is user-written javascript and CSS for this, written by Anomie; it only works in reading mode, not when editing in either wikitext or VE. I have it installed in my own js and css files, and it is indeed very useful. The conversation above is about the fact that work by the VE team was required before a script to do similar highlighting while editing in VE was possible. This has been done, so now a script could be written, by Anomie or someone else with the relevant skills. I don't think this is a high priority to include in core VE when it is easily scriptable; and it seems like something many users will want to tweak and customize (different colours, etc.). Mike Christie (talk - contribs - library) 22:07, 11 September 2014 (UTC)

Thanks for the comment. I know there is a script but not everyone wants to use a script or knows how to do it or even know that they exist. We are just saying here that it would be a good idea if it could be included on VE as default and no scripts would be needed. Of course as you say it's not a priority and it doesn't have to happen tomorrow but it's nice to have a report about it out there in case that it's possible to happen and the VE team can work on it in the future :)) TeamGale 22:26, 11 September 2014 (UTC)

Thanks for sharing your opinion. I have no strong view about it either way—could be very helpful, might be a bit confusing, people would probably get used to it–so it's very helpful to me to hear what other people think about this idea. Whatamidoing (WMF) (talk) 17:33, 12 September 2014 (UTC)

Autoupdate citation list

When I use VisualEditor to add a citation, the list of citations (i.e., the reflist template) never updates, so it's not possible to see what the citation list will look like after the page is saved. I assume this is a known issue, but I couldn't find a bug for it in Bugzilla. Could someone point me there? Thanks! —Neil P. Quinn (talk) 21:42, 7 September 2014 (UTC)

I believe this is a WONTFIX; {{reflist}} will not update until the actual save, although < references/> would. — Arthur Rubin (talk) 00:05, 8 September 2014 (UTC)

Permanently wontfix? Do you know why that is?—Neil P. Quinn (talk) 00:38, 8 September 2014 (UTC)

It's been described here as more CANTFIX than WONTFIX, but I'll let someone who understands the reasons explain. Mike Christie (talk - contribs - library) 01:08, 8 September 2014 (UTC)

Yes, it's really CANTFIX. I don't recall all the details, and I'm not sure that I ever fully understood them. However, to the extent that memory serves, the basic issue is that templates don't update visually unless you specifically re-process them. There is no way to know which templates might need refreshing. (Here at en.wp, about a quarter of articles use {{reflist}}, but there are other templates in use here, amd other projects use other ones). Making this happen all the time for all templates would be a serious performance problem.

My suggestion is that if the reflist template is plain (zero parameters), that you should replace it with the native <references /> list, which will not only update immediately in VisualEditor, but which will also be slightly faster for readers and slightly reduce your risk of hitting the transclusion limit on the article. Whatamidoing (WMF) (talk) 19:38, 8 September 2014 (UTC)

Okay, thanks for the explanation. I'll consider that workaround. For the record, I'm a big fan of Visual Editor, Flow, Hovercards, and all the other projects the Foundation is working on. Keep up the good work!—Neil P. Quinn (talk) 20:09, 8 September 2014 (UTC)

Whatamidoing (WMF), I doubt that there is no way for VE to know that there's a <references /> that is currently being displayed, and that it comes from a given template in the page.

For example, if I "inspect element" with Chrome on Petter Nilssen, I clearly see an <ol>...</ol> tag for the <references /> (

<ol class="references" typeof="mw:Extension/references" about="#mwt22" data-parsoid="{"src":"<references group=\"\"></references>"}" data-mw="{"name":"references","attrs":{}}">

...) which is inside a block generated by a {{Reflist}} (

<div class="reflist  ve-ce-leafNode ve-ce-focusableNode ve-ce-focusableNode-focused" style=" list-style-type: decimal;" about="#mwt19" typeof="mw:Transclusion" data-mw="{"parts":[{"template":{"target":{"wt":"Reflist","href":"./Template:Reflist"},"params":{},"i":0}}]}" data-parsoid="{"stx":"html","dsr":[2964,2975,null,null],"pi":[[]]}" contenteditable="false">

...). So, there's a way to know which templates might need refreshing, all the information is already available in what is displayed by VE in editing mode.

--NicoV ^{(Talk on frwiki)} 21:35, 8 September 2014 (UTC)

(Sorry, I meant CANTFIX, rather than WONTFIX. One of the bugs I mentioned here was WONTFIX.) Actually, I don't agree with NicoV. VE doesn't know that the HTML generated by {{reflist}} needs to be redisplayed, and I, at least, don't know what VE "sees". If it only sees {{reflist}}, then it doesn't know know what needs to be updated. If it sees the HTML, it may not know what template needs to be updated. Only if it sees both the template and the HTML, might it know what needs to be updated, and if {{reflist}} were part of another template. I suppose some process could refresh any instance of the < references > tag, wherever it appears in the HTML, but it wouldn't know when to refresh. It would be inefficient to the point of unsuitability to do it on any edit. I haven't used VE lately, but it could have a "purge" (current display) button. — Arthur Rubin (talk) 01:13, 9 September 2014 (UTC)

Arthur Rubin: VE works with the HTML and the DOM, which is annotated by Parsoid to know what wikitext is producing. So VE has all the information required to find which templates in the page are producing references list. It just needs to go through the DOM to find the references list either by looking for the correct value in attributes typeof ("mw:Extension/references"), data-parsoid or data-mw. From then, it can go up in the DOM hierarchy to find the actual element which includes the references list in the final output. --NicoV ^{(Talk on frwiki)} 05:00, 9 September 2014 (UTC)

Actually, NicoV, I don't fully agree. Even if it knows what it's supposed to update, how often should it do so? On each keystroke? — Arthur Rubin (talk) 05:09, 9 September 2014 (UTC)

Arthur Rubin, for me, that was the easy part. Unless I'm mistaken, it's not possible to edit references directly in VE, you always have to go through an inspector or other tool (like the "Cite" tools, or the "Template" inspector). So, references can only be modified in dialog boxes, and so the update needs to be done only when leaving such inspectors. It's also probably possible to know if the block you have just edited contains or contained references to limit even more the number of updates. --NicoV ^{(Talk on frwiki)} 06:59, 9 September 2014 (UTC)

Actually, Whatamidoing (WMF), now that you've explained the issue, I do see a fix on the roadmap now. Under "working on right now," it lists "References—Editors can set options like column width and list styling for reference lists in the dialog, and do not have to use {{Reflist}} templates or the like." This should make it possible to use <references /> almost everywhere and eliminate the need for {{Reflist}}.—Neil P. Quinn (talk) 01:36, 9 September 2014 (UTC)

"(Here at en.wp, about a quarter of articles use {{reflist}}, but there are other templates in use here, amd other projects use other ones). " From Template:Reflist: This template is used on 3,000,000+ pages. That's 3/4, not 1/4. One would think that getting the most basic and arguably important template we have for our articles would be a high priority fix. But then again, even the very simple and logical suggestion to have a PREVIEW, made months ago, hasn't been implemented yet. Fram (talk) 07:07, 9 September 2014 (UTC)

The transclusion count includes all namespaces: 3.2 million transclusions out of 33.7 million pages. Only about a million of those are in the mainspace. Try Special:Random a few times, and count the results. You will find that three out of four articles does not have that template. Whatamidoing (WMF) (talk) 17:23, 11 September 2014 (UTC)

Yes, because so many pages in other namespaces have a reflist template... Random articles?

José Valentín reflist
Świniec (river) nothing
Primavera Online High School references
Miguel del Rey Vicente nothing
Sarchat-e Badhava reflist
Classic Diamonds – The DVD reflist
Saint Anthony's Catholic High School nothing
List of lakes in Yellowstone County, Montana reflist
Carbon Hill, Alabama references
Kathiramangalam reflist
Gary Burnstein Community Health Clinic reflist
Danny Godby reflist
Nematabad, Rafsanjan reflist
St. Leo's Roman Catholic Church, Mimico reflist
Gol-e Kharg reflist
Kristen Babb-Sprague reflist
Ben Fitzgerald reflist
Big Pile of Mud nothing
Nathaniel Philip Rothschild reflist
Purgatory Correctional Facility reflist
Succession (geology) nothing
Joe Volpe reflist
Gaita transmontana nothing
Delcídio do Amaral reflist
North Lanarkshire Council election, 2007 reflist
Afa Ripley, Jr. reflist
Dahut nothing
Thar Express reflist
Margarete Klose nothing
Tatie Danielle references
Eversen (Bergen) references
Danielle Ammaccapane reflist
Craig Johnson (ice hockey b. 1972) reflist
Lothingland reflist

So, of 34 random articles (got bored then, feel free to repeat it with more articles), 8 have no reference template, 4 use the VE-favourite "references", and 22 have reflist. 22/34 is nearly 65%, which is slightly closer to my 75% than your 25%. Now, if you have any actual evidence for your figure, feel free to share it. Otherwise, don't try to support your claims with wild and wildly inaccurate guesswork. This isn't the first time that you made the same type of error, it gets rather annoying. Fram (talk) 18:56, 11 September 2014 (UTC)

Fram, I'd already done a similar sample:

Neither: [4][5][6][7]

Reflist template: [8][9][10][11]

Mediawiki core feature: [12] [13] [14][15]

–and one dab page, so the reflist template was used on 4 out of 13 mainspace pages, which is a lot closer to 25% than to 75%. Now it could be that my sample size happens to be the outlier–or, of course, that yours could be. If it is very important to you, then you could request a database report. That would give you the complete count rather than possibily erroneous samples. Whatamidoing (WMF) (talk) 19:21, 11 September 2014 (UTC)

Just did another test: 28/50 had reflist. So yes, your sample was too small by far. But the issue is not that it is very important to me or not, the issue is that you are very happy to use your imagination to fabricate some numbers that suit you, but can't or won't produce actual figures or statistics when they are asked and needed, and that on the other hand you are very quick to dismiss statistics that don't suit your POV even though you are unable to produce better or to indicate any flaw in them (or use completely ridiculous "flaws" like the 33 million pages above). Add to that that your POV is nearly always the WMF POV, and it becomes hard to see you as a useful or trustworthy community liaison or as a useful discussion partner in general. The sad thing is that most people who only encounter you here occasionally won't be aware of that, so a regular reminder of the problems is useful for everyone (well, everyone but you probably, but 99.9% is fairly close to 100%, no?) Fram (talk) 19:41, 11 September 2014 (UTC)

Oh, and from your sample, [16] uses the reflist template. Getting 1 out of 13 wrong, nice... Fram (talk) 19:52, 11 September 2014 (UTC)

John Hygdon doesn't use the reflist template. It doesn't use any form of WP:Inline citations at all. "Template is present on the page" and "template is used" are not the same thing. Whatamidoing (WMF) (talk) 20:34, 11 September 2014 (UTC)

@Whatamidoing (WMF): @Fram: Perhaps we should be focusing on articles that are most frequently edited? Speaking only from personal experience, the vast majority of article that I've edited in the past year use the reflist template. My sense is that it's the stub articles, which - obviously - few people edit, that lack the reflist template (or, as noted above, any way to display references on a page).

The point is that the reflist template is extremely widely used, and extremely important to experienced editors. Fixing VE problems related to it should be a high priority. -- John Broughton (♫♫) 14:21, 15 September 2014 (UTC)

Table formatting modified by VE

Hi, in this edit, VE modified the formatting of 2 tables (apparently the tables were not modified by user) : parameters reordered, modified, removed, ... I was unable to reproduce it. Apparently, VE detected that something was odd since the edit was tag as to be reviewed. --NicoV ^{(Talk on frwiki)} 19:52, 13 September 2014 (UTC)

Other similar example. Please stop VE from making dirty diffs, this was requested a lot of times, agreed upon, but it keeps going on on a regular basis and makes verifying a modification a lot more difficult than necessary. What's the point in putting color codes in lower case, or replacing hexadecimal color codes by rgb() calls, or changing order of table parameters ? --NicoV ^{(Talk on frwiki)} 12:11, 14 September 2014 (UTC)

Different example, still showing a big dirty diff for only a few real modifications. --NicoV ^{(Talk on frwiki)} 12:44, 14 September 2014 (UTC)

Other examples: 3rd example, 4th example, 5th example... --NicoV ^{(Talk on frwiki)} 15:28, 14 September 2014 (UTC)

The table formatting mess is due to Microsoft Internet Explorer's particularly brittle handling of some types of HTML. The devs are working on a patch right now, with the hope of stopping this problem about five hours from now (plus time to get it deployed). If it's not fixed in today's emergency deployment window, then you can expect IE11 to be blacklisted again. They send their sincere apologies for the unexpected page corruption bug. Whatamidoing (WMF) (talk) 17:47, 15 September 2014 (UTC)

Cut and paste of a table gives nowiki

Tracked in Phabricator
Task T72857

In this edit, it seems that the user just cut and pasted a table. The result is that VE added a lot of unnecessary new lines and nowiki tags in the cells of the title line, instead of keeping the table as it was. --NicoV ^{(Talk on frwiki)} 15:22, 14 September 2014 (UTC)

That's very strange. I can reproduce this in Safari and Firefox, so it's likely affecting everyone. I've filed it as T72857. I'm not sure whether the problem is really VisualEditor or Parsoid. Whatamidoing (WMF) (talk) 18:41, 15 September 2014 (UTC)

References format modified by VE

Tracked in Phabricator
Task T57461

A different example of dirty diffs made by VE. Apparently, the contributor only added a sentence, and VE modified several totally unrelated reference tags (adding a white space before "/>", adding quotes, ...). Same request as above: stop making dirty diffs. --NicoV ^{(Talk on frwiki)} 12:53, 14 September 2014 (UTC)

This is believed to be a problem with Parsoid. They've made progress on it, but not enough. If you've been seeing a lot of this since last Thursday, please let me know, because that would indicate a problem with IE11. (Adding quotation marks is correct HTML, and IE11 is less tolerant of incorrect HTML than most other browsers.) Whatamidoing (WMF) (talk) 18:45, 15 September 2014 (UTC)

VE finally working in Internet explorer!

I just made a VisualEditor edit to TV Tropes [17] in Internet Explorer 11, and I saved it! --User J Dalek 01:44, 12 September 2014 (UTC)

Oh, I see it's already official [18]. --User J Dalek 05:07, 12 September 2014 (UTC)

But it still says it doesn't work at WP:VisualEditor. Eman235/talk 08:14, 12 September 2014 (UTC)

You're right; we need to get all the documentation updated. This change is less than 24 hours old. NB that it's only IE11 right now. IE10 is next on the list. I don't know how long it will take, but it may be several months. Whatamidoing (WMF) (talk) 17:34, 12 September 2014 (UTC)

Also, whenever I make an edit, the edit notice always says I'm using a browser that doesn't support VE. --User J Dalek 02:09, 15 September 2014 (UTC)

Perhaps we should defer updating the documentation until the warning message is fixed? -- John Broughton (♫♫) 14:10, 15 September 2014 (UTC)

I believe that it was scheduled to be off the 'graylist' (the browsers whose users get warnings), but there's yet another IE-specific HTML corruption issue, so if it hasn't been whitelisted yet, then it really shouldn't be until that's patched. (If it's not fixed in time to catch the next deployment window (~5 hours from now), then IE will likely be blacklisted until that one is fixed.) Whatamidoing (WMF) (talk) 17:44, 15 September 2014 (UTC)

@Whatamidoing (WMF):Translation? --User J Dalek 00:31, 16 September 2014 (UTC)

This morning (California time), Catrope said that he planned to fix a problem with IE11 in time for the late afternoon (also California time) emergency deployment window. If not, they were going to have to turn off access to VisualEditor for people using IE11 (temporarily). If you can still use VisualEditor, then he was successful. (The problem involved replacing functional wikitext with allegedly "ideal" [according to IE11] wikitext, except that what it really did was create a mess for anyone looking at the diffs.)
We have three "lists" of browsers: those that are expected to work (whitelist), those that are known to be broken (blacklist), and those that are believed to work (at least sometimes) but aren't officially considered supported and/or stable (graylist). IE11 was blacklisted until last Thursday. It was promoted to graylist with the last major update. It was supposed to get promoted to whitelist status soon (but not until it had been used for a while, to make sure that it really did work most of the time). I'm not sure what it's current status is, but since a significant problem was found, I doubt that the warning will go away today. Whatamidoing (WMF) (talk) 01:22, 16 September 2014 (UTC)

Oh, I understand now. Thanks. (PS, I can still use VE, but the warning's still there.) --User J Dalek 02:18, 16 September 2014 (UTC)

nowiki around whitespace just before a colon

Tracked in Phabricator
Task T73006

Hi, in this edit, VE added totally unecessary nowiki tags around the whitespace before the colon. --NicoV ^{(Talk on frwiki)} 07:45, 17 September 2014 (UTC)

That's very strange. Thanks for the note. I'll see what I can figure out about it. Whatamidoing (WMF) (talk) 17:21, 17 September 2014 (UTC)

The VisualEditor devs believe that this is a Parsoid bug, so it's now T73006. I'm not certain, but that first pair of nowiki tags may be wrapped around a non-breaking space. Whatamidoing (WMF) (talk) 16:10, 19 September 2014 (UTC)

Section editing and edit conflicts

I saw a note from a very experienced editor the other day saying that they prefer to use VE for copyediting, but because of the risk of edit conflicts they can't do so if they see someone else is editing (a vandal, in this case) because of edit conflicts. I think if it were a vandal I'd just go ahead, save at the end, and overwrite the vandal's edits, but the general case is an issue.

In T50429, the one for section editing, I suggested that hiding/collapsing other sections might be a way to give the appearance of individual section edits in VE. That would also address the edit conflict problem: the current wikitext editor is smart enough not to complain about conflicts when two different sections are being edited. If VE is restricted to a section, presumably the same intelligence could be used to avoid complaining about edit conflicts with VE. Is there any reason why that wouldn't work?

If that would work, then I'd like to see the team move this up on the schedule if possible. I understand the reasons for the low priority it has been given, but that seems to be because any form of section editing would not solve the speed or edit conflict issues and would be very difficult because of the risk of parsing partial HMTL. If the "hiding" option can be made to work, it means that two of those three issues would not be a problem any more. Issues that stop editors using VE for straightforward large scale copyedits (which is what VE is best at) seem like the sort of thing we should try to prioritize -- this is not a power user request; it's the sort of thing a new editor is likely to want to do. Mike Christie (talk - contribs - library) 12:40, 24 September 2014 (UTC)

I don't think this will help as much as we all wish it did. If I blank the article while you're editing section #12, then you're going to get an edit conflict. I just tested this, using purely the wikitext editor: working in a section did not protect my edit from the "vandal" (my other account).

"Section" editing only protects you if the vandal is not editing the same paragraphs that you are–and there's nothing "magic" about the "section" part. If you are editing section #12 while the vandal is busy (only) in the lead (or, to be more precise, any paragraphs except the ones you're currently editing and the lines adjacent to them), then MediaWiki will correctly resolve the changes. It correctly resolves the changes if you edit the whole page in the wikitext editor, if you edit only section 12 in the wikitext editor, and if you edit the whole page in VisualEditor. (Check the page history for my sandbox to see some proof, or try it out yourself.) The vandal-versus-editor test has the same result in all cases.

I certainly understand not wanting to edit an article that's being actively edited, but you should be getting the same level of edit conflicts regardless of which editor you're using (assuming you're doing the same work: the main "problem" with editing the whole page in VisualEditor is that it's very tempting to fix a problem that you see out of your area, and the more lines [not sections] you touch, the more likely you are to encounter an edit conflict [no matter which editor you're using]). Whatamidoing (WMF) (talk) 17:08, 24 September 2014 (UTC)

If I understand you correctly, this is excellent news. Just to confirm I have it right: if you're editing a long article in VE, and you edit six of ten sections, and someone else edits one of the other four in wikitext, there will be no edit conflict? Mike Christie (talk - contribs - library) 12:57, 25 September 2014 (UTC)

There should be no edit conflicts. There are a couple of things you could do that would throw the system off (some complicated rearrangements of the sort that diffs handle so poorly), but usually it will be just fine and invisible to both editors. Whatamidoing (WMF) (talk) 16:06, 25 September 2014 (UTC)

Group refs question

I couldn't figure out how to set up a footnote within a note. Comet (magazine) is the article I was working on; the single "note" has a footnote citation within it to Bleiler. This revision, created with VE, is close to what I wanted, but I also wanted to add a citation within the note (as the current version does). Inside the note editing dialog there's the option to add a cite, but there's no "cite basic" option at this level, so as far as I can tell it's not possible to do what I wanted to do. Is there any reason not to add "cite basic" and "reuse" to the cite menu inside this dialog? Mike Christie (talk - contribs - library) 21:04, 14 September 2014 (UTC)

About a year ago, you could create nesting refs in VisualEditor, and they displayed as intended that way. However, the cite.php system itself doesn't support this: when you save the page, the nested ref disappears. That's presumably why the ability to (mistakenly believe that you were successful in your quest to) create nested refs was removed from VisualEditor.

Do you think it would be a widely used feature? If so, we could ask James F to put it on the list of non-VisualEditor editing improvements that we'd like to see next year. Whatamidoing (WMF) (talk) 18:59, 15 September 2014 (UTC)

Can you clarify what it is that wasn't working? The current version of Comet (magazine) does have a nested ref; are you saying that is not something supported by Mediawiki, but instead provided by local template engineering on en-wiki? Mike Christie (talk - contribs - library) 01:19, 16 September 2014 (UTC)

What doesn't work is <ref>Explanatory note<ref>Citation</ref></ref>. The solution you settled on uses a parser function. Where did you find that approach? Whatamidoing (WMF) (talk) 01:25, 16 September 2014 (UTC)

It's all over WP:FA; I found it a few years ago and use it in almost every article I write. I haven't looked at the template code so I'm not clear on the underlying mechanism. See also the system used in Norman Conquest of England, which may be the same system underneath: it uses {{efn}}, but I haven't looked under the hood to see how it works. Mike Christie (talk - contribs - library) 01:31, 16 September 2014 (UTC)

I remain astonished at how ignorant the WMF developers are of how articles are formatted, and the supporting templates such as {{efn}} and {{reflist}}. I guess that comes from none of them having any idea of how to write an article themselves, but that's hardy an excuse. How many FA editors have they consulted with? Obviously I realise that in the present climate every IP vandal is worth far more than any registered user, but surely even for the WMF there has to be a limit? Eric Corbett 01:48, 16 September 2014 (UTC)

That's where I would have gone to look, too, Mike. I have finally also found it documented at WP:REFNEST (aka "the obvious place" ;-). Do you think it would be worth adding a link to it at WP:CITE?

By the way, it's not a template; it's a parser function (part of the core software). Anything starting with {{# is a parser function. It looks like the {{efn}} template does the same thing under the hood. Whatamidoing (WMF) (talk) 20:18, 16 September 2014 (UTC)

Re adding a link at WP:CITE: maybe, but I'd suggest asking there -- I don't spend much time at those internal discussion boards and am not very familiar with the page. Most of what I've learned has been by copying other articles.

Does the fact that it's a parser function mean that there is a chance VE will support this functionality in the future? I can see that the templates that make use of this might be harder to handle, but can the pure {{#tag:ref call be added to the options for insertion within VE? Mike Christie (talk - contribs - library) 21:57, 16 September 2014 (UTC)

I believe that this will be included in the work for the "support parser functions" bug. However, I don't think that will happen any time soon. At that point, you might have to insert it as a "template".

Another approach would be to make nested refs functional. Would that be desirable, or cause more problems that it's worth (e.g., inexperienced people accidentally nesting refs when they shouldn't)? Whatamidoing (WMF) (talk) 16:13, 19 September 2014 (UTC)

I don't think it would be worth making nested refs functional; we already have a way to achieve this, so I think it would be better just to have VE implement what is already doable in wikitext. Mike Christie (talk - contribs - library) 09:38, 26 September 2014 (UTC)

Three tries, three fails

Random article, first I got was Results of the Victorian state election, 2010 (Legislative Council). Open in VE, takes somewhat long, doesn't look like the original page. Click on the first box on the screen, click on the "Australian elections/Title row" box, template opens. Try to move the box to the right, so I can see the template (in the article) and the template edit box next to each other, so I know which parameter is feeding which "box" in the template. Can't move the template edit box. Give up. Try to find a method to edit the numbers per party inside the template. Can't find a method. Give up.

Second random article: Malamarismo. Try to edit the tracklist in VE. Parameters are given in alphabetical order, not in order of article. Useless. Give up.

Thrid try. Charles Landon Knight. Open the infobox (infobox congressman). "An infobox for office holders. It is generally better to use a more specific template like {{Infobox politician}}." Strange. Can I convert this to another infobox? Of course not. Do I need to? Of course not, this is a more specific template. If you would use infobox politician (like on Maurice Duverger), you would get the exact same message instructing you to use "Infobox politician" instead of, er, "Infobox politician". Why? Because template data aren't made with redirected sub-infobox-templates in mind, even though these are used very frequently. Give up.

Three tries, three fails. One case where I can't edit what I want, one where I can but it is easier and more user friendly in wikitext, and one where I get completely wrong advice which I can't easily follow in VE anyway. In all cases, I would have been better off editing in the wikitext editor (and in all cases, I needed to know wikitext anyway to edit what I tried to do). Please drop me a note when VE really works. I won't hold my breath. Fram (talk) 06:58, 24 September 2014 (UTC)

Results of the Victorian state election, 2010 (Legislative Council): Opening the page in VisualEditor takes less than two seconds in Safari and about two seconds in Firefox. It looks like the original in both Safari and Firefox. I had no trouble changing the number of votes that each party received in the template-created table. It's a complex transclusion and works like any other complex transclusion: Find the template you want in the left, choose the parameter you want, and change the value in the field. Moving the box would not have helped you see which parameter feeds which box, because template contents do not auto-update as you type. None of the changes you made would have been visible in the table until after you clicked "apply changes". (Of course, if this were just a table, then you'd have no trouble changing the contents in VisualEditor: click on the number you want to change, and change it. But you couldn't add new rows to such a table in VisualEditor yet, and it would be much uglier to deal with a heavily formatted table in wikitext.) Whatamidoing (WMF)
- Obviously, if you test it after someone has corrected the page so that it does work in VE[19], you won't have the same problems. And moving the box would have helped me, to see the match between current (pre-change) field on the screen and in the template... Fram (talk) 19:23, 24 September 2014 (UTC)
  - Broken tables are broken, regardless of whether they are created with templates or wikitext. Unclosed tables should not be tolerated by the community, because although it looks "correct" on some browsers, it is broken in others and some screen readers. Does it display correctly for you when you open it in VisualEditor now? Whatamidoing (WMF) (talk) 19:32, 24 September 2014 (UTC)
Parameter order is always given in the order that was specified in the TemplateData by an editor here at the English Wikipedia. Anyone who believes that a different order would be preferable is free to re-order the TemplateData into something more sensible. This is entirely under the control of the community. Whatamidoing (WMF)
- And what if, like in this case, no template date is given? Oh right, then VE chooses the alphabetical order, not the order already used in the article or the order in the template syntax. Fram (talk) 19:23, 24 September 2014 (UTC)
  - Yes, if the community chooses not to add TemplateData, then you get the default. Whether to provide non-default order is up to the community. Whatamidoing (WMF) (talk) 19:32, 24 September 2014 (UTC)
    - And the default is useless. Whether to use the order used in the template, or in the article, is up to the Ve developers. Alphabetical order is mindless and useless. Fram (talk) 19:42, 24 September 2014 (UTC)
The description provided by TemplateData was the choice of an editor here at the English Wikipedia. If you believe that the description is wrong, then you can certainly change it, i.e., by providing individual TemplateData for each infobox instead of re-using the same, one-size-fits-some TemplateData for all of them. This is entirely under the control of the community. Whatamidoing (WMF) (talk) 17:30, 24 September 2014 (UTC)
- Right... I added the template data description to the template[20], and it doesn't work. Perhaps I did it wrong, no idea, but the result is what it is... Fram (talk) 19:23, 24 September 2014 (UTC)
  - Did you purge the template afterwards? Whatamidoing (WMF) (talk) 19:32, 24 September 2014 (UTC)
    - No, why? I did try it out on another article after changing the template though. Have you purged it and tried it, or are you just asking random questions instead of checking things? Wouldn't be the first time (see this very section, where you blamed template data for a problem, even though the template didn't have templatedata...) Fram (talk) 19:42, 24 September 2014 (UTC)
      - Maybe you would have done this because you read the directions at Wikipedia:TemplateData/Tutorial#Save, which say that TemplateData needs a null edit to purge the page if you want it to work right away, rather than waiting for whenever the database catches up with your edit? Whatamidoing (WMF) (talk) 20:54, 24 September 2014 (UTC)
        And that straw broke as well after you grasped it. Even though now a night has passed instead of the few minutes that page mentions, nothng changed. I now made a null edit[21], makes zero difference. Whatamidoing (WMF), you are consistently giving wrong, irrelevant or badly informed answers, never bothering to try if they are even correct or useful. Can you please just leave my questions alone and let someone else answer them? You are not helping me, yourself, the WMF, or other readers (apart from demonstrating your role and the waste of money it is) and are just one big annoyance here. How many attempts will you need to get it finally right, like a broken clock probably. Fram (talk) 04:38, 25 September 2014 (UTC)
        If you don't perform the null edit, then I'm prepared to guarantee that it won't work for a while (especially given the state of the job queue earlier this week). However, while your failure to do that would have prevented your change from appearing, that's not the only way that TemplateData fails. (You may have noticed that I asked a question about whether you'd taken this step, instead of saying "if you make a null edit, it will definitely start working.") Only one TemplateData block is processed per template. Because {{infobox congressman}} is a redirect, the TemplateData block on the redirect page may be taking precedence over the one that you added. Providing custom TemplateData for different merged templates might require that the TemplateData be moved out of the common documentation page and placed individually on each of them. Whatamidoing (WMF) (talk) 05:53, 25 September 2014 (UTC)
        If you had bothered to check what I had done (and which I linked), you wouldn't talk so much bollocks. Bye, Whatamidoing, please don't reply, you are a nuisance here. Oh, and either a liar, someone with a spectacularly short memory, or someone who doesn't know what they are talking about. My money is on the third. "you can certainly change it, i.e., by providing individual TemplateData for each infobox instead of re-using the same, one-size-fits-some TemplateData for all of them. This is entirely under the control of the community." doesn't really match "(You may have noticed that I asked a question about whether you'd taken this step, instead of saying "if you make a null edit, it will definitely start working.")" You said what I should do, you said that I can "certainly" change it, that is "entirely" under our control, and told me what to do. It doesn't work. Then you proceed by saying that you never said it would work, and by giving all kinds of instructions and possibilities which don't match what I did (and what you suggested) at all. Either because you haven't checked and prefer your fantasies over reality, or because you don't understand what you are saying. In either case, just shut up. You have gotten enough chances to get it right here, you have failed miserably at each attempt. I have asked you after your first replies here to stop, but you simply continue. I have no idea what you are trying to achieve here, going out with a bang or something, but you are very fast becoming very disruptive. Fram (talk) 06:52, 25 September 2014 (UTC)
        I haven't looked at these three issues myself, so I can't comment, but for the sake of anyone else reading this thread I think it's only fair to Whatamidoing (WMF) to say that she has been helpful, diligent, and knowledgeable whenever I have asked her a question. Fram, something you might consider is that the method you're taking of providing negative feedback is probably not as productive as you would like. Other editors may react differently, but when I read something like your comment above, my reaction is: "that editor lost their temper, so it's probably over-reaction; I doubt it's nearly as bad as that"; and I lose any interest in investigating the situation to find out if you are right. If you want to convince editors like me of incompetence at the WMF or by Whatamidoing (WMF), you'd get further by dropping the invective and being clear and dispassionate about the issues. Mike Christie (talk - contribs - library) 12:52, 25 September 2014 (UTC)

(unindent)I asked Whatamidoing below to stop responding, after her first set of incorrect replies. I asked her again above ("Can you please just leave my questions alone and let someone else answer them?"). She then again responds with a totally incorrect reply. This isn't the first time that she pulled the same tricks. The time of being dispassionate and calm about this has long passed. You are lucky if she has been helpful, diligent and knowledgeable in your cases. When I encounter her, she is usually giving the appearance of being helpful, but by displaying a total lack of diligence and knowledge ends up being the exact opposite. Just look at my pst and her hopefully final reply here:

Me: "I now made a null edit[22]" She: "If you don't perform the null edit,[...]" I did, I just said so!
Her own post, further up in this discussion: ""you can certainly change it, i.e., by providing individual TemplateData for each infobox instead of re-using the same, one-size-fits-some TemplateData for all of them. This is entirely under the control of the community." Her final post: "(You may have noticed that I asked a question about whether you'd taken this step, instead of saying "if you make a null edit, it will definitely start working.")" No, Whatamidoing, you said that we could certainly change it and that it was under our control, you didn't just ask a question
Her post: "Because {{infobox congressman}} is a redirect, the TemplateData block on the redirect page may be taking precedence over the one that you added. Providing custom TemplateData for different merged templates might require that the TemplateData be moved out of the common documentation page and placed individually on each of them." She is so "diligent" and "helpful" that he hasn't bothered to check what I did, which is exactly what she suggested. I don't even expect her to try anything before she gives a suggestion, I have given up that hope long ago, WMF people are not interested in testing. But when one tries something out, gives the diffs, explains what has been done, the last response one wants is "have you tried doing the thing you have just done?" No, you utter waste of time, I haven't, how stupid of me, have a barnstar. This is just analyzing that last reply, but every single one before that had similar problems and show her total lack of understaning, her failure to grasp the individual problems, never mind the overall image.

If this kind of nonsense happened once, big deal, we all have bad days. But this happens way too often to be coincidence or bad luck. This is incompetence. And when you notice that someone is not competent enough to answer questions on a discussion and feedback page, you ask them to stay away and stop providing "answers". If that doesn't help, you make them stay away. Fram (talk) 13:16, 25 September 2014 (UTC)

Fram, when I said "if you don't perform the null edit", I mean, "every single time you edit TemplateData on any template at all, if you don't perform a null edit", it's not going to work. I did not mean "You still haven't done it". I know that, after I asked whether you had performed this critical step, you did so.

However, contrary to your assertion here, you have not provided the TemplateData on "each infobox". You have provided (extremely limited) TemplateData on one. Did you move TemplateData out of the common doumentation page? No. (I have underlined some relevant phrases in your quotation above.) Do you still have two TemplateData blocks on that template "instead of" just one on the redirected template? Yes. Is the system still limited so that it pays attention to just one block? Yes. Is it going to work like you want while you've still got two blocks, each of which contain different and only partly overlapping information about the template? No.

Just to be crystal clear: Will moving the documentation out of the common template guarantee that your other block will start working? No. This is a JSON system. It's brittle. If you've got something so seemingly minor as a missing comma, it's not going to work. There are dozens of ways to break TemplateData. We have only talked about two of the most common errors, both of which you have made.

And finally, since your real problem appears to be the contents on the common documentation, which provides you with a one-size-fits-some description that tells people already using a specific template that they ought to use a specific template, why don't you just change that documentation? There's nothing stopping you from changing "It is generally better to use a more specific template like {{Infobox politician}}." to read "It is generally better to use a more specific template instead of {{Infobox officeholder}}." or "It is generally best to use the most specific template; see the documentation at {{infobox officeholder}} for the list." Or even "The documentation is [here]." (I wonder if that advice makes any sense, now that all the templates have been merged into it. The end result is the same no matter which you use.) Whatamidoing (WMF) (talk) 15:48, 25 September 2014 (UTC)

First, do not change anything in the post I made. Change your own post, or reply with your emphasis, but don't emphasis in my post that wasn't in the original and that I didn't want or need to add. You have a point to make, make it in your own post. Talk page rules 101.

Second, thanks for clarifying that this (your solution) simply won't work. You have nicely tried to wiggle yourself out of your own trap, but of course failed miserably. Why would I need to add templatedata on each infobox? On every single infobox that redirects to the central one, just to correct one of them? That absolutely makes no sense. Just like it makes no sense that you can't have templatedata on the central one if you want the templatedata on the redirect one to work. What if you want both? Basically, what you are saying without wanting to say it out loud (of course, let's not be open and clear, shall we) is that it doesn't work, that you have been and are still making things up as you go along, that you haven't got the foggiest whether anything you said and say will have any effect, never mind the wanted one, but that you just try to keep me busy in a fake civil way so that you will look patient and nice instead of bewildered and out of your depth. Why don't you have a go at correcting it, instead of making incorrect claims about what should be done and then claiming that of course this or that wouldn't work afterwards? Fram (talk) 19:09, 25 September 2014 (UTC)

Let me see if I can be even clearer about what you are calling "my solution":

Do not ever have two TemplateData blocks. It will always discard extra blocks. (The most common problem is having one block on the template page and another on the template's /doc page, but it is location-independent; two back-to-back TD blocks on the same page cause the same problem.) The request to change this behavior was made and refused months ago. (If multiple blocks can be used, then the upcoming parameter dependencies, i.e., if there's a |month=, then you also want a |year=, can't be checked reliably upon saving the TD block.)
- You can have different TemplatData on each template. If you want {{Infobox congressman}} to have TemplateData that is different than the TemplateData on its (common) doc page, you must remove the TemplateData block from the doc page. You might need to unmerge the template (how TemplateData does and will interact with this type of redirect is uncertain and may change; you will recall that I said there are still multiple ways for this to fail even if you correct the two errors we have discussed at length now), but you must reduce the number of TemplateData blocks to one.
- If you don't want people yelling at you for removing TemplateData on the common doc page, and thereby removing it from the other 50-odd templates that are using that common TD block, then, yes, you are going to have to edit all 50-odd templates to give each of them their own copies of the TemplateData that you just removed from them.
- If making 50-odd copies of TemplateData sounds like too much trouble just to change the description (it does to me, and that is why I never actually recommended that you create separate TD blocks for every template), then you could try a a very quick, easy, and simple copyedit on the existing description. As I said originally, the description supplied in that TemplateData block on the common documentation is entirely under the control of the community. Changing it is, by far, the easiest way to remove the description that you dislike, and it has the happy effect of fixing the description on all 50-odd templates at once. This is my actual solution for your complaint about the description: Change that one description.
Make a null edit to every template (not the doc page) whose TemplateData you change.

Finally, the reason that I'm not going to change the description myself is that staff don't normally make content changes. What that description says is entirely under the control of editors. Whatamidoing (WMF) (talk) 22:18, 25 September 2014 (UTC)

"I never actually recommended that you create separate TD blocks for every template". No? ""If you believe that the description is wrong, then you can certainly change it, i.e., by providing individual TemplateData for each infobox instead of re-using the same, one-size-fits-some TemplateData for all of them. This is entirely under the control of the community.". But I guess you'll wriggle your way out of this by claiming that that wasn't a "recommendation", simply a very misleading answer where you knew all along that it wouldn't work anyway. Get lost. Fram (talk) 04:34, 26 September 2014 (UTC)

Fram, from what you said above it seems you want to make Whatamidoing (WMF) go away and stay away ("When you notice that someone is not competent enough to answer questions on a discussion and feedback page, you ask them to stay away and stop providing "answers". If that doesn't help, you make them stay away."). It's also apparent from her comment to you on her talk page that her job requires her to reply to you on this page. I think if you want to stop her from posting on this page, the two ways to do that would be to convince the community that she should be banned from this page, or to convince her boss that she is not doing her job. Do you realize that the tone you're taking makes it unpleasant for other users to read this board? I come here because I use VE as my primary editor and I want to get news and feedback about it. The interactions between you and Whatamidoing (WMF) frankly make me, and I would think others, want to avoid this place. Surely that's not an outcome you want? Mike Christie (talk - contribs - library) 09:25, 26 September 2014 (UTC)

I have informed her boss yesterday, [23]. As long as the WMF person, whose job it apparently is to reply here to editors, gives way too often such incorrect or irrelevant replies, then yes, I don't mind that people want to avoid this place. Places where you routinely get bad advice are usually to be avoided. Fram (talk) 09:45, 26 September 2014 (UTC)

I think it would be better to start an RfC. As it is you're taking unilateral action to influence the editing of other contributors without having consensus from them that that's a good thing to do. How would you feel about starting an RfC to achieve what you want? Mike Christie (talk - contribs - library) 10:04, 26 September 2014 (UTC)

I have no trust in RfC/Us anyway, and they are not binding. What would there be to achieve? The WMF doesn't respect RfC's with massive and clear consensus anyway, so having a small one about one employee is unlikely to achieve anything. As for "unilateral action", yes, that's what I'm doing. I haven't presented my complaint as a community issue or a consensus for which I'm the spokesperson, I have presented it as my complaint. The WMF didn't need consensus to appoint a so-called "community liaison" defending their product here, no matter if you want her to do so or not, as she is forced by her boss to reply, whether she knows the answer or not. You like her input, I don't. It is too often deceitful, wrong, or badly informed. The above discussion is a perfect example. Ignore the long discussion about the third example for a moment, and go back to the second one, about "tracklist". Her reply is "Parameter order is always given in the order that was specified in the TemplateData by an editor here at the English Wikipedia." Nice, seemingly helpful, probably correct, but... misses the point entirely. The template I was discussing doesn't have TemplateData, so the "answer" isn't an answer at all. It's like someone asking "why do lines that start with a space get displayed in a box?" and giving the answer "it's standard markup that when you start a line with a semicolon, the text is bolded". And that's the kind of "discussion" (if you can call it that) that you get way too often with Whatamidoing. Take a look at Wikipedia:VisualEditor/Feedback/Archive 2014 4#Autoupdate citation list, where Whatamidoing gives a way too percentage for the prevalence of "reflist" in our articles. Trying to correct her is fruitless, her rather definite claim turns out to be based on a very small sample of articles and a complete misunderstanding of where these templates are used, but no evidence to the contrary will change her view or make her redact her claims, which just happen to support what the WMF wants and not what enwiki uses... If she doesn't know a thing, she should just say so, or indicate that she will ask the devs or whoever; but making things up as she goes along in the hope that it will be correct or that no one will notice it is a rather dreadful way of acting. Fram (talk) 10:44, 26 September 2014 (UTC)

So, thank you Whatamidoing (WMF), three answers, not one of them relevant or correct. Can you ask someone from the WMF who actually knows what they are doing (if any can be found) to respond in the future? As this was simply a waste of time. Fram (talk) 19:23, 24 September 2014 (UTC)

All this has nicely deflected us from the main issue. Not what is wrong with individual infoboxes or articles or editors, but what happens when random, somewhat experienced editors start using VE. If you get an experience like described here, most people won't try to find the VE problem or edit the templatedata (yeah right) or come here to complain; they'll close VE, won't look back, and continue editing with the wikitext editor, probably muttering something about the stupid WMF wasting their money. Which probably explains in part why at the wiki's where VE is the default, almost no established editors have made the switch to it, and a vast majority of editors of who registered after VE became the default make their edits with the wikitext editor as well.

VE is still filled with many small and not so small things that don't work, work in an illogical way, don't give the expected result, or require wikitext anyway. It is of little to no benefit to most editors, so why should the vast majority of people ever want to use it? Correcting one page of the 4 million plus we have is nice, but it's a drop in the ocean. Fram (talk) 19:27, 25 September 2014 (UTC)

Stub (and other) tags

In VE, I have no idea how to remove a tag that indicates an article is a stub. I tried clicking on the text, which then turns blue. But delete, backspace, and ctrl delete do nothing. And there is no error message or tip. If I right click, one promising option comes up, but if I click on that (I can't remember what it's called, and I don't want to go there again), my entire screen gets messed up with meta-text scattered all over it, and I can't get out of it with-out leaving Wikipedia entirely. Kdammers (talk) 10:14, 25 September 2014 (UTC)

Kdammers, this should be very easy: select the template and backspace. I've done it several times (example). Can you tell me which article you were trying to fix? Whatamidoing (WMF) (talk) 16:14, 25 September 2014 (UTC)

I don't recall what the article was, but I now have a similar problem at Gross Lengden. I copied a photograph from the commons but mis-understood the labeling instructions with the near invisible box borders. So, I put what I thought was the caption in the wrong place. When I went back to fix it (after I had submitted the edit: I couldn't see the picture in the preview), I couldn't figure out how to get back into editing the picture's associated text. So, I uploaded another copy of the photo and properly labeled it. I thought I would then delete the original picture. However, that was not to be. I'm not sure what you mean by "select" - I don't see a button with that name. I can highlight the picture by mousing over it. But then none of my keys do any-thing. I just gave up and saved the mess, went over to the regular editor and in a second or two made the deletion. Kdammers (talk) 05:57, 26 September 2014 (UTC)

Kdammers, it sounds like you were having pretty serious problems.

When you added the image, you should have seen something like the image here. Did the dialog look significatly different? Would it help to make the lines around the boxes be darker?

I'm not sure why the image didn't display for you. Did you change anything in the Advanced tab? (Something there might have moved it to an unexpected position.) Is this a consistent problem for you?

"Highlight" and "select" are the same thing, but "hover" is different. If you click one time on an image with your mouse, or if you use arrow keys to move the cursor over it, the image should be selected (and turn light blue on most people's computers). Whatamidoing (WMF) (talk) 00:07, 29 September 2014 (UTC)

Awesome

This is a very easy way to edit a page & extremely useful for non professional users. TrueOfficer (talk) 07:13, 27 September 2014 (UTC)

Thanks for the feedback, TrueOfficer. I'm glad that you had a good experience. There are still some things that need a lot of work, and I hope that you'll let us know if you run into any problems or have ideas for making it easier to use. Whatamidoing (WMF) (talk) 00:39, 29 September 2014 (UTC)

Use positional parameters for templates with no parameter name chosen?

This is more a suggestion than feedback. I was helping someone edit Tarzan (1999 film) and they wanted to add the {{Main}} template using the visual editor. I didn't know how to do it, so we guessed. We selected Main from the templates then (as I would with a template edited in source) pasted in Tarzan (Disney franchise), what we got was {{Main|Tarzan (Disney franchise)=}} which renders as "Main article: <Whatever the current page name is>" (that specific quirk is due to how Module:Main falls back when parameters aren't supplied). After looking at the template field again I noticed that the first step after selecting a template is to post a parameter name, then the value. Strictly speaking this is PEBKAC, but if I know the value I want for the first parameter is there any benefit to inserting {{Main|1=value}}where the parameter name isn't in the template data?

Alternately, for templates with relatively few parameters (e.g. 1-4), there should be a way to specify in template data the parameter names which can be preffilled. So instead of having a dropdown list based on the user typing the parameter names, they can be rendered as a input fields with the parameter name on the left and a space to add the value on the right (with a little button saying "add" or something). This wouldn't work for large templates, but for smaller ones (where the template authors explicitly provide the prefill instructions in template data) a user can quickly get to adding the value that they want without typing out the parameter name. Protonk (talk) 14:16, 26 September 2014 (UTC)

Protonk, there's TemplateData on that template. When you Insert > Template for "Main", then you should get a list of parameters (the first says "Page 1, The name of the first page that you want to link to..." The idea is that you click on the parameters you want and fill them in. Would it be helpful enough to make the obvious one (people almost always want to add only the one) already appear in the list, so that instead of "Field" (for the parameter name) you're presented with "Page 1" and a blank for the article name? Whatamidoing (WMF) (talk) 01:00, 29 September 2014 (UTC)

Up and down arrow keys

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	Move the cursor
Steps to Reproduce:	#Edit a section Press up or down arrow Press up or down arrow more times
Results:	Sometimes the cursor moves, sometimes the view window moves
Expectations:	The cursor moves
Page where the issue occurs	Add URL(s) or diffs
Web browser	Chrome 37.0.2062.120 m
Operating system	Windows 8
Skin	Monobook/Vector
Notes:	Any additional information. Can you provide a screenshot, if relevant?
Workaround or suggested solution	Add one here if you have it.

Lfstevens (talk) 08:05, 27 September 2014 (UTC)

Thanks for the note, Lfstevens. I don't have Chrome or Windows 8 installed, but Safari's similar to Chrome (both WebKit browsers). The window/view jumping every second or third time I pressed an up or down arrow key was annoying. However, I kept careful count, and it moved the cursor to a new line each time. Could you check this for me, and let me know if the cursor moves every time for you, too? I want to make sure the details are correct for the bug report. Whatamidoing (WMF) (talk) 00:51, 29 September 2014 (UTC)

AFAICT the cursor does change lines each time. At the edge of the view area, an arrow key triggers the the view area to move and the cursor is no longer displayed. Lfstevens (talk) 01:56, 29 September 2014 (UTC)

Unexpected behaviour editing a link

Suppose I want to insert a link to Foobar but mistype it as Barfoo. I spot the error and edit the text, which is now a red Barfoo, so that it says Foobar. What I get is now [[Barfoo|Foobar]] which is certainly not what I intended. This seems counter-inituitive. Deltahedron (talk) 08:19, 27 September 2014 (UTC)

I agree with you. How exactly to make this clear is a design challenge.

One of the recent proposals was to ask people. Imagine that you type "Barfoo" and make a link to it (or that you open a page that already has a link to Barfoo). Then you change the visible text (the link label) to something (anything) else, e.g., "Foobar". VisualEditor would ask, "Did you want to repoint this link from <Barfoo> to <something else>?"

This might get annoying, though: If you had a link to [[apple]] and you wanted to make a grammar correction, i.e., [[apple|apples]], then it would ask you if you wanted to repoint the link to the {{r from plural}} redirect apples. What do people think? Would it be worth it? Do you have other ideas that might be less annoying? Whatamidoing (WMF) (talk) 00:48, 29 September 2014 (UTC)

I am surprised this "challenge" was not thought of and met a couple of years ago. Unfortunately I cannot support development resources for some of the design problems you've presented due to other large-scale priorities and resources. I will simply not be able to say yes to all requests. That is part of the process. This being said, for your suggestions for development ideas, this is an ongoing process, and you are welcome to present your ideas for how we include and involve all users in working on product development together in general. Deltahedron (talk) 06:48, 29 September 2014 (UTC)

I hadn't realized that this problem occurs in other situations than has been described last week. It makes me lean toward the conclusion that use of VE, creates sufficient errors, even by skilled editors, that it should not be allowed on en.Wikipedia (or any website which allows piped links) until the "challenge" is resolved. I don't know what the resolution should be. I can only see the present situation is intolerable.

My best guess as to acceptable solution would be to require a separate confirmation for creating a piped link, with no default option, if "status quo ante" cannot be determined. In other words, if no specific answer is given, the entire edit session needs to be cancelled. (In other words, [ESC] cancels the edit session, if there is no input as to which of [[Foobar]] or [[Barfoo|Foobar]] (or possibly [[Foobar|Barfoo]]) is intended.

A possible alternative is to violate the "visual" aspect by displaying a piped link as a piped link. At least, that way, the editor can see what is going on. In other words, displaying [[foo|bar]] as foo|bar, or something like that. (Note that what I wrote is not valid HTML 5.) — Arthur Rubin (talk) 10:43, 29 September 2014 (UTC)

I'm not clear why this is a problem. I just tried editing Ten Story Fantasy, which has a link to The Sentinel (short story), piped from visible text of "Sentinel from Eternity". When I place the cursor there to start editing, it says "Sentinel (short story)" right underneath my cursor, showing me that it's a piped link. If I edit a link that isn't piped, such as BBC, a few words later, again it shows "BBC" right underneath my cursor, and it continues to say that after I change the text of the link, indicating that it's going to be piped. What more is needed? Perhaps mark the pop-up in some way to mark it harder to miss the fact that it's piped? E.g. change "[link icon] BBC" to "[link icon] Note link goes to: BBC". The sudden change in the pop-up as the user types over the link would make this hard to miss. Mike Christie (talk - contribs - library) 11:38, 29 September 2014 (UTC)

On wikis where VE has been activated by default, like frwiki, everyday there are many examples of actual edits performed by newbies or experienced editors, where this problem does happen. It's frequent enough that we even discussed adding a specific detection in Check Wiki project for this problem, but we could only catch basic errors like [[2013|2014]]. This problem has been reported several times, and each time the answer seems like the VE team simply doesn't want to handle it... --NicoV ^{(Talk on frwiki)} 13:34, 29 September 2014 (UTC)

Do you think the approach I suggest above would reduce the frequency of the errors you're seeing? Mike Christie (talk - contribs - library) 13:46, 29 September 2014 (UTC)

(edit conflict) As suggested (and ignored) several times, the best solution would probably be to limit the "visual" approach here. A Wiki-link consists of two separate elements: the actual link and its visual representation. Both elements need to be displayed clearly and distinct from each other. Anything else leads to confusion and the mentioned errors. Admittedly such an approach will be slightly slower to edit, but it will be more user-friendly and less prone to errors. Another point: Separating redirect and direct links in the selection list is another bad idea, redirects are valid links and should not be listed separately. GermanJoe (talk) 13:52, 29 September 2014 (UTC)

(edit conflict)It has been suggested (quite a while ago, and a few times since) to have a link interface with "link to this article" and "display this text" fields (actual text to be decided, and the second by default the same as the first), to make it clear to editors what the link is, and what the displayed text. This hasn't been adopted (AFAICR, it has been rejected by Jdforrester, but I haven't checked so this may be an incorrect memory on my part). Fram (talk) 14:00, 29 September 2014 (UTC)

I agree; something like that would be a good idea. However, the errors that NicoV is reporting don't appear to be made by interacting with the link dialog, which is where the changes you suggest would be; they seem to be caused by editing the text on the page directly without going to the link dialog. I haven't found this confusing myself, but if others have (as is evidently the case) then I think the popup that shows up when you click on a link is what needs to be modified. Users who never get to the dialog won't be helped if the dialog is improved. Mike Christie (talk - contribs - library) 14:11, 29 September 2014 (UTC)

I agree it's difficult to find a good solution here, the only thing I'm sure of is that the current design is bad. My first suggestion would be to modify the current link dialog to have both fields (destination and displayed text). My second suggestion would be to automatically display the link dialog when typing text inside a link so that users would really see what they are doing. --NicoV ^{(Talk on frwiki)} 15:32, 29 September 2014 (UTC)

What I would do is make the popup box for links have two fields, one for the actual link target (A) and one for the text displayed (B). B could be auto-filled with the text selected and need not be changed. This is clear, intuitive, and controllable.--Salix alba (talk): 16:09, 29 September 2014 (UTC)

The user interaction least likely to cause errors is to have link dialog that show both what will be displayed to readers and where the link goes to. (In Microsoft Word, the fields are labeled "Display" and "Link to"; I'll used that terminology.) The "Display" field should be on top, so it doesn't get in the way of the link-to search functionality.

When creating a link, the "Display" field should "echo" what is being typed into the "link to" field, unless (a) the user started by highlighting some text (in which case, the display field should contain that text until edited directly), or (b) the location being linked to begins with "http" (in which case, the display field should stay blank until edited directly).

The user should be able to edit an existing link only through a link dialog, one that shows both fields. Yes, that's slightly slower, and slightly less WYSIWYG. But, as pointed out many times before by developers, VE isn't explicitly intended to be a WYSIWYG editor. And, as the above comments note, letting an editor directly edit the display text of a link is a significant, recurring cause of errors. By forcing the user into a link dialog, we guarantee that he/she understands exactly what the link does, and exactly how it displays to readers. -- John Broughton (♫♫) 23:53, 29 September 2014 (UTC)

John, can you give me a clearer idea of how MS Word handles this?

Here's what I did in Google docs, which is very similar to how VisualEditor handles it:

Type a "Display" label: Foo
Make a link to a URL: Select Foo, press Command-K, see two-field link dialog, add http://example.com for the URL. (Close the dialog; go off and edit other parts of the document if you want.)
Place cursor inside the "Display" label (e.g., in between the two o's of Foo), and change the text to say anything other than Foo.

It's that last step that's causing this particular problem. What does MS Word do there? Does it pop the link dialog open again, or just let you change the displayed label directly? Whatamidoing (WMF) (talk)

Suport the two field approach. Lfstevens (talk) 00:25, 30 September 2014 (UTC)

References

I thought this was solved a while back, but either I imagined it or it has regressed a bit. When you open a page like Bearden Waterworks, the refs switch position (what is ref 1 in the standard view becomes ref 2 in the VE mode and vice versa), but only in the text. The numbering in the infobox stays the same, which is totally confusing of course. Furthermore, you now get the "stop, no access" icon when you click on "ref 2" in the text, but you can open the "basic" ref anyway: you don't get to see it though, you get an empty screen.

Now, if you type something into that empty ref box, you create a ref with the text you just typed, but with the same ref name as the one in the infobox.

All this is very counterintuitive and confusing. This is not something happening on one or two pages only, things like Round Church (Richmond, Vermont) have this but also major articles like United States. Fram (talk) 08:29, 30 September 2014 (UTC)

Have VE list all cite templates?

Currently, VE only lists the most commonly used citation templates. There should be a way to access a list of all cite templates from the citation menu (i.e., a "more" button). You technically search for other cite templates from the "Template" option, but most of these don't have the documentation brought over, so they are effectively useless.--¿3family6 _contribs 23:34, 29 September 2014 (UTC)

You first go to Cite > Basic, and then to Insert > Template.

The Cite menu does the same thing in the end; it is just letting you do this in one click instead of two, and it only displays the template dialog. If someone had added a citation template to the Cite menu without first adding TemplateData documentation, then you would still have the same "effectively useless" problem.

I believe that the more common citation templates usually have the TemplateData (e.g., {{Cite press release}}), but that most of the less popular ones (e.g., all of the Vancouver templates) don't. Which ones in particular did you want to use? Whatamidoing (WMF) (talk) 00:32, 30 September 2014 (UTC)

I did try adding the template that way, so I think it's a documentation issue. I was trying to insert a {{Cite AV media}} tag. I ended up switching to source text.--¿3family6 _contribs 01:18, 30 September 2014 (UTC)

I've added it to the list at Wikipedia:TemplateData#Used_in_main-space_(>5000_uses), so hopefully someone will finish the description there. Whatamidoing (WMF) (talk) 20:37, 30 September 2014 (UTC)

Problems and minor issues

Tracked in Phabricator
Task T52809

Tracked in Phabricator
Task T52882

Tracked in Phabricator
Task T72218

Categories; the dropdown doesn't work properly. When you are adding a category and you are unlucky enough that there is enough space to the right of the last category, you get a much too small drop down menu, where most of the category names is "..." (strangely, some suggested cats get a "..." in the middle and one at the end of the cat). The box isn't resizable. Worse is that the scroll bar doesn't work, when you click it the dropdown simply closes again. You can use the up- and down arrows, but that's far from optimal. The scroll bar problem has been mentioned already some months ago.

New categories stil are added after stuc templates and so on. It would be nice if they were added with the other categories.

Categories can't be reordered.

You can add a sortkey to individual categories, but it isn't recorded (not when adding a category and not afterwards)

Advanced settings. The first two, "Let this page be indexed by search engines" and "Show a tab on this page to add a new section" are as far as I know never used on articles. Can these be namespace-specific so that they aren't shown on articles (the main target of VE).

Page settings vs. advanced settings: Page settings should be the common three "redirect", "disambiguate", and "displaytitle"; all the others are very rarely used and should be "advanced" or not displayed at all (as mentioned above).

Categories should be the first among the options as it is the most commonly used of these options

As mentioned before; it makes no sense to have a dropdown with "options", "page settings", and so on, if the options then simply list the others ("page settings" and so on) again. Either remove options and only keep the other ones (in the order as described above), or only have "options" and "switch to source editing" and discard the rest in this dropdown.

Why do the dropdown menus on the left have a dropdown arrow, but not those on the right?

When I open a template, I can select the template name (in "show options" mode) and remove it (trash can icon). But I can't apply the change. Seems strange, this is a nice way to remove templates (e.g. hidden ones). Fram (talk) 13:21, 25 September 2014 (UTC)

The sort key problem needs a new bug report.

The scrollbar problem is a design problem: You can scroll with your fingers (on a laptop trackpad), mouse wheel, or with the arrow keys. If you click on it, it closes without adding a category. Design problem: if "click on it" is repurposed to become the third way to "scroll", then how would you close the search list without adding a category? Whatamidoing (WMF) (talk) 00:36, 29 September 2014 (UTC)

Don't most modern systems show different behaviour when you click on the scroll bar (or its arrows on top and bottom) compared to anywhere else in the box? Thta's rather basic... How would I close the box? With an X in a top corner, or a "close" button, or something else? I know, revolutionary ideas, wil take some time for the WMF devs to get around to them probably. A bit like a special character inserter that let's you add more than one character probably. I'm willing to discuss design issues, but I don't think that "using the scroll bar as a close button" is really a design issue, it's a clear bug. No priority, not assigned... Fram (talk) 08:09, 29 September 2014 (UTC)

Missing bugzillas

Apparently, no bugzillas have been made for the following problems above (some may have already existed in Bugzilla but just not been noted here, e.g. it isn't clear to me whether bug 54705 (created: September 2013, status: NEW) is related to any of this; but I certainly couldn't find anything in Bugzilla for the bugs among the below list):

Categories: a much too small drop down menu
box isn't resizable (general problem, mentioned here in conjunction with the previous one
You can add a sortkey to individual categories, but it isn't recorded (not when adding a category and not afterwards)
Advanced settings. The first two, "Let this page be indexed by search engines" and "Show a tab on this page to add a new section" are as far as I know never used on articles. Can these be namespace-specific so that they aren't shown on articles (the main target of VE)?
Page settings vs. advanced settings: Page settings should be the common three "redirect", "disambiguate", and "displaytitle"; all the others are very rarely used and should be "advanced" or not displayed at all (as mentioned above).
Categories should be the first among the options as it is the most commonly used of these options
it makes no sense to have a dropdown with "options", "page settings", and so on, if the options then simply list the others ("page settings" and so on) again. Either remove options and only keep the other ones (in the order as described above), or only have "options" and "switch to source editing" and discard the rest in this dropdown.
Why do the dropdown menus on the left have a dropdown arrow, but not those on the right?
When I open a template, I can select the template name (in "show options" mode) and remove it (trash can icon). But I can't apply the change. Seems strange, this is a nice way to remove templates (e.g. hidden ones).
Add a "basic cite" (or open an existing one), drop-down the "use this group", and you get the upper half of the text "general references". If you get multiple groups, like on William Shakespeare, then you can't even see the other groups.
William Shakespeare: I tried to open the references section in VE, but then the script just kept hanging.
Lakeland School District, Pennsylvania. Open in VE, scroll to "Eight grade", PSSA results. Change the results? You get a template box, with a lot of col templates. Go through them on the left (click "col-begin", "content", and so on), and you see the cursor move down on the right side. Go through all the fields in this way. What do you get? Nothing! Is the content missing? No, it is only invisible, you need to actually click inside the right-side content boxes. Try it with the first one! Oh, right, that one's empty...
Wikitext in TemplateData descriptions doesn't work, see e.g. the description of reflist

Thirteen nicely numbered suggestions (a few) and errors (also a few). Perhaps some nice soul with Bugzilla access will add these there? Some will disappear in the black hole, but perhaps some will get picked up. Otherwise this feedback page becomes even more of a waste of time than it usually is. Adding me in CC in Bugzilla would be a nice exra, but isn't mandatory... Fram (talk) 10:53, 3 October 2014 (UTC)

Various VE errors in the recent changes

Hi, I've just checked what problems are visible in the last edits with VE on frwiki. Here's a list of problematic edits, a lot of them have already been reported several times, and still nothing has been done to fix them:

Totally unnecessary nowiki tag added in Alphagel
Empty lines starting with one or several "*" or ":" in Matériau composite, Les Fleurs du mal, Pont Neuf, Système dynamique, Mésange bleue, David Tennant
Incorrect modification of links (cf. previous discussion) in FIFA 15, Viguier d'Andorre, Yannick Choirat, Philippe Ramette, Dr. Bériz, Dr. Bériz, Pseudo-Geber, Total (entreprise), 1665, Hypothèse
Space after link included in the link in Steven Moffat
Italic formatting with only a nowiki tag inside in Stromae
Pawns in Marquis Surcouf
Poor formatting with sup tags added around whitespace characters in Henri Vackier
Damaged internal link (solution for previous discussion would help on this also) in Plonéour-Lanvern, Plomodiern, Plogonnec, Plogoff, Plogastel-Saint-Germain, Rosetta (sonde spatiale)
Empty title in Accordéon
Damaged table in Liste des conseillers généraux du Calvados, Power Rangers : Dino Charge
Paragraphs turned into titles in Charles Antoine Manhès, Lettres à une disparue
Categories and DEFAULTSORT deleted in Roger Nicolet, Roger Nicolet
Table formatting modified in Liste des personnages de Resident Evil
Text converted to [tel:...] in Démographie de la Champagne
Internal link with only a nowiki as text in Thomas Edison

That's only in less than 500 edits done with VE, and I didn't report the numerous acts of vandalism which seem more frequent than with the wikitext editor. --NicoV ^{(Talk on frwiki)} 19:36, 29 September 2014 (UTC)

Thanks for the list, NicoV. Elitre and I spent a long while trying to reproduce the Steven Moffat "linked space" error earlier this month, and we made no progress. Would you mind asking that user for browser and OS information, and if s/he has any idea what he might have done there? Whatamidoing (WMF) (talk) 00:46, 30 September 2014 (UTC)

I asked the user. I tried editing Steven Moffat with VE, that's just awful:

Go 2 pages down using "page down" key: the display is scrolled to the left, the beginning of the lines becoming invisible
Go 1 more page down using "page down" key, move the cursor above the references (blue area is displayed above the references), go 1 more page down: the blue area has changed into a reversed L shape covering both the references and the chapters after
Go to the end of the article using Ctrl+End, go 1 more page down using "page down" key, go 1 page up using "page up" key: the display is scrolled again to the left, the beginning of the lines becoming invisible. If the mouse cursor is over the palette templates, the blue area is shifted to the right

Win 7, Chrome. --NicoV ^{(Talk on frwiki)} 20:15, 30 September 2014 (UTC)

A way of reproducing the "linked space" is described at frwiki: using backspace to remove characters after an existing space. --NicoV ^{(Talk on frwiki)} 22:07, 2 October 2014 (UTC)

The "unnecessary" nowiki tag was added in Alphagel because l'''Alphagel'' is a mismatched number of single quotation marks.
There was no nowiki tag before and it was working correctly, so the nowiki is unnecessary. And as discussed before, if it was necessary, it should be added around the single quote not around a part of the paragraph. --NicoV ^{(Talk on frwiki)} 09:37, 30 September 2014 (UTC)
NicoV, Quote handing is complex, and how a sequence of quotes are parsed involves a whole bunch of heuristics that requires lookahead to end of line, and is influenced by what else is seen on the line. When converting HTML back to wikitext, where a nowiki is needed is not a simple matter of examining content nearby. So, in order to avoid writing complex/unmaintainable code, we occasionally insert defensive/conservative nowikis to prevent changing semantics of wikitext. That said, we'll do another pass over over nowiki handling sometime soon and see what else we can cleanup. We think it is more important to preserve rendering/parse semantics of wikitext over some excess nowikis that we end up adding (and dirtying). I am not trying to minimize your concern and revulsion of seeing the unnecessary nowikis, just trying to clarify that this is a difficult problem and that we have made some tradeoffs which we will revisit again. Thanks for your understanding.SSastry (WMF) (talk) 18:53, 30 September 2014 (UTC)
Empty list items in Matériau composite and similar are due to the user leaving an empty bullet item on the screen. This can't be fixed in software, or you could never create a list with blank placeholder items (which might not be wanted in encyclopedia articles, but is wanted in other types of documents).
Wrong again, many editing sofwares are able to deal with this without keeping unnecessary formatting in the end result. By the way, an empty list item is incorrect, and you can see in the result produced by MW that empty list items are discarded. --NicoV ^{(Talk on frwiki)} 09:37, 30 September 2014 (UTC)
NicoV, Parsoid does not strip empty tags in top-level content, because then it can never be edited in clients (and either removed/or content added to it). It is always left behind. We considered hiding it with CSS, but that runs into the same issue of not being editable. We do strip them from template content since those are not directly editable. So, this part is likely going to be incompatible with PHP parser unless we find a reasonable way of dealing with this. SSastry (WMF) (talk) 18:41, 30 September 2014 (UTC)
Incorrect modification of links — I agree with your comment in the previous discussion: it's difficult, but we need to find a way to improve it.
Italic formatting with only a nowiki tag inside in Stromae will be due to blanking everything, but retaining the character formatting. This is probably "works as intended", because if you remove a word or line, people expect the character formatting to be retained.
Pawns in Marquis Surcouf are an attempt to retain the character formatting.
Poor formatting with sup tags added around whitespace characters in Henri Vackier is "working as designed"; it's irritating as an editor to have someone select everything, including the space, change the format, and then select only part of it and undo the format. However, the alternative is to forbid people from producing valid wikitext markup just because it might be a mistake, rather than, e.g., an effort to shrink the size of the space (which is done, although people shouldn't do that).
I disagree: it's possible to handle this properly as it is done in many editors. Retaining formatting while editing without polluting the end result is possible. --NicoV ^{(Talk on frwiki)} 09:37, 30 September 2014 (UTC)
Please give me an example of an editor that allows you to set a character format on spaces, and then silently discards that formatting upon save. I might be able to save you some time: Google docs doesn't; Apple Pages doesn't; Apple Mail and Gmail don't; MS Word didn't the last time I used it; WordPerfect was famous for bloating file size by never doing that; no Adobe page layout software has ever done that. This is easily checked: type a words, two spaces, and another word. Select both spaces and set the character formatting to bold (or superscript or green or whatever you want). Save the page. Open it again, place your cursor btween the two, abd see what happens when you type. (The point behind using two spaces is to find out the formatting of the spaces themselves; different programs have different rules about taking formatting from the characters that precede or follow the cursor.) Whatamidoing (WMF) (talk) 20:22, 30 September 2014 (UTC)

(More later.) Whatamidoing (WMF) (talk) 01:07, 30 September 2014 (UTC)

I'm sorry, but your answers seems to be as usual "It's not VE's fault but the users fault" while my opinion is clearly "It's VE's fault". Every time your answer is "working as desgined", I'm thinking that the design is bad because it's not working as it should. I disagree with you when you say that some problems can't be fixed in software, that's just that you don't want to fix them. Every problem I reported above needs an other editor to fix VE errors, that's a loss of our time. As usual, reporting problems seems useless. --NicoV ^{(Talk on frwiki)} 06:50, 30 September 2014 (UTC)

I agree that there are some bad designs here. However, in several of these cases, we have to choose between the least-bad of several limited designs, because there isn't a good solution that works for every project. Whatamidoing (WMF) (talk) 20:22, 30 September 2014 (UTC)

Pawns? still

I am very surprised to see that VE is inserting pawns into articles, still, in Q4 2014..?? Whatamidoing (WMF), what do you mean by "Pawns in Marquis Surcouf are an attempt to retain the character formatting." I had assumed from upbeat VE IRC office hours that these types of problems had been fixed. Are these pawns regressions, or have the issues causing pawn insertion not been fixed yet? I see a few existing bugs, some with quite low bug id. Are they all still valid bugs? What is the priority of this and other pawn problems. John Vandenberg ^(chat) 03:17, 3 October 2014 (UTC)

I don't know whether these are regressions or simply one of the same problems as before. I don't expect them to specifically fix those open bugs for pawns, because they are replacing the entire pawn-based system right now. The replacement is in patch-to-review state as of this morning, and when that lands (which may take a few weeks, depending on how testing goes), there will be no more pawns. Whatamidoing (WMF) (talk) 18:10, 3 October 2014 (UTC)

TemplateData autovalue and VE

Hi, I'm trying to use the new "autovalue" attribute for TemplateData, and I don't understand how it works with VE. I tried adding an autovalue to template "Admissibilité à vérifier" on frwiki for parameter "date"

First attempt with an autovalue of {{safesubst:CURRENTMONTHNAME}} {{safesubst:CURRENTYEAR}}: when I try to insert the template with VE, the dialog automatically adds parameter date with the correct value. If I then click insert, the template is inserted, but without the autovalue: the date parameter is empty.
Same test, but if I change the value proposed for date, the template is correctly inserted with the value. Apparently, the value is only taken into account if I modify it, which can of defeats the purpose of autovalue...
Other attempt with an autovalue of {{CURRENTMONTHNAME}} {{CURRENTYEAR}}: when I try to insert the template with VE, the dialog automatically adds parameter date but without any value.

--NicoV ^{(Talk on frwiki)} 10:10, 3 October 2014 (UTC)

The correct syntax is mw:Help:TemplateData#Auto_value. I'm not sure what the situation is with that. It's never worked for me, but I can't remember whether the problem is that the template itself has to be supplying the value (e.g., if you don't specify |section=, then the template will supply the word "article" here) or if the problem was that this feature hadn't been turned on yet (so you could pre-define the TemplateData this way, but it was going to be ignored until the next update). Whatamidoing (WMF) (talk) 18:17, 3 October 2014 (UTC)

The feature isn't enabled yet in VisualEditor. You can expect to see it on 16 October (subject to change as a result of testing, of course). Whatamidoing (WMF) (talk) 18:37, 3 October 2014 (UTC)

The problem is that the feature is partly enabled in VE: in some cases, it picks up the autovalue and adds it in the template dialog, but it's not taken in account when saving. --NicoV ^{(Talk on frwiki)} 06:44, 8 October 2014 (UTC)

Image didn't show up in search

I tried to change the image of the ethene molecule to File:Ethan_Keilstrich.svg, but when I pasted that in the search bar (might have had a space before it), it didn't show up as a result. User:GKFX^talk 15:58, 8 October 2014 (UTC)

Just to confirm, it was the space that caused the problem: removing it made the search succeed. User:GKFX^talk 16:00, 8 October 2014 (UTC)

I'm glad you got it worked out. VisualEditor can only show what Search is giving you, and Search doesn't always give us quite everything that it should. (The most frustrating one for me is when you give it the complete, exact file name, and it says there's nothing, but then you give it only the first half of the file name, and it finds it immediately.)

There's a lot of work being done on the search systems this year, and I think this is steadily improving. Whatamidoing (WMF) (talk) 16:41, 9 October 2014 (UTC)

Can't differentiate between SVG and PNG files.

Tracked in Phabricator
Task T74061

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	I was trying to use an SVG file rather than the PNG version.
Steps to Reproduce:	Opened the add image dialog to the search page, and typed "Chloroethane-skeletal".
Results:	It was impossible to tell which result was the SVG.
Expectations:	File extensions shown in results.
Page where the issue occurs	Add URL(s) or diffs
Web browser	Firefox 32
Operating system	Ubuntu 14.04
Skin	Vector
Notes:
Workaround or suggested solution	Pick images at random and use tool-tip text to check extension.

User:GKFX^talk 16:13, 8 October 2014 (UTC)

Hi User:GKFX,

Yes, that's obviously a problem with this design. The next round of improvements to the image dialog should fix this. One of the open questions is whether you'd like to be able to see just the full file name (Example.png, Example.svg) or whether you'd like to be able to see the file type as a separate field (JPEG, PNG). I suppose the latter might be more reliable if the file name is a million miles long (presumably there's some practical limit to what can be displayed), but overall I don't have strong views.

Eventually (probably meaning no sooner than 2017) they hope that it will be possible to search by file type. When MediaWiki's search tools support that, then VisualEditor will add that feature. Whatamidoing (WMF) (talk) 16:51, 9 October 2014 (UTC)

Bug in Save page dialog

Tracked in Phabricator
Task T65316

If I opt to resume editing in the Save page dialog, the next time I try to save the two edit summaries drop-down boxes are repeated. If I resume editing again they're repeated as many times as I resume editing. Caiaphodus (talk) 19:06, 5 October 2014 (UTC)

Hi Caiaphodus,

That's a known problem, and needs to be fixed in the gadget. Whatamidoing (WMF) (talk) 16:55, 9 October 2014 (UTC)

Italics and nowiki

Can VE automatically use {{'}} in edits like this and this? Ed ^{[talk] [majestic titan]} 22:48, 12 October 2014 (UTC)

Unfortunately, VisualEditor cannot depend on any local templates, because local templates do not exist everywhere that VisualEditor does. Whatamidoing (WMF) (talk) 18:20, 14 October 2014 (UTC)

Visual editor adds unwanted quotation marks

Tracked in Phabricator
Task T57461

In this edit VE added additional quotation marks to reference names, although in my edit I only changed "Patrich" to "Patrick". Δρ.Κ. ^{λόγοςπράξις} 00:26, 13 October 2014 (UTC)

This is an old, difficult bug in Parsoid. Whatamidoing (WMF) (talk) 18:23, 14 October 2014 (UTC)

Autofill "date accessed" field when adding citations

It would super-useful if the "date accessed" field was automatically filled out with the day's date; it's what users will be entering 99.9% of the time. Popcornduff (talk) 20:40, 13 October 2014 (UTC)

I second the suggestion. This is exactly the sort of thing that would help make VE (eventually) the preferred way of editing - because it's smarter than wikisource editing. -- John Broughton (♫♫) 15:47, 14 October 2014 (UTC)

Try using the "autovalue" attribute of TemplateData, it's supposed to be used for that kind of thing. I don't think VE handles it properly right now (see this discussion) but it's supposed to in the future. --NicoV ^{(Talk on frwiki)} 15:51, 14 October 2014 (UTC)

It's already in place for mw:Citoid's citation autofilling system (coming to a wiki near you, maybe by the end of the calendar year). Autovalue will eventually (allegedly, "soon-ish") do this for all marked templates, which will be very helpful for cleanup templates like {{fact}}. Whatamidoing (WMF) (talk) 18:27, 14 October 2014 (UTC)

Alt text not saved

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	I was trying to add alt text to images I'd changed to SVG.
Steps to Reproduce:	Typed in the alt text box after changing the image.
Results:	No alt text anywhere in the diff; no indication that I'd even tried to add this text. I couldn't recover the text by switching to source mode.
Expectations:	Alt text appears in diff.
Page where the issue occurs	Add URL(s) or diffs
Web browser	Firefox 32
Operating system	Ubuntu 14.04
Skin	Vector
Notes:
Workaround or suggested solution	Do the whole thing in source mode.

User:GKFX^talk 13:04, 10 October 2014 (UTC)

User:GKFX, I can't reproduce this either in Safari or in Firefox. Can you double check for me and let me know if you're still having problems with it? You can edit my sandbox if you'd like. You can see that the alt text was added here when I tried it in Firefox (on my Mac). If you're still having problems, it might be OS specific, and I don't want to miss the bug if that's the case. Whatamidoing (WMF) (talk) 18:39, 14 October 2014 (UTC)

Categories moved into ref tags

Tracked in Phabricator
Task T74048

Already reported some time ago, but it's still happening. When will it be fixed ? --NicoV ^{(Talk on frwiki)} 22:17, 11 October 2014 (UTC)

Other example, this one cutting an external link in two pieces... --NicoV ^{(Talk on frwiki)} 22:18, 11 October 2014 (UTC)

And again. 15 months that VE has been deployed, and it still damages articles on a daily basis... --NicoV ^{(Talk on frwiki)} 13:13, 12 October 2014 (UTC)

Oh, these are especially ugly... Doesn't seem to happen on enwiki, although neither I nor probably anyone else actually checks VE edits for recurring problems anymore: we have more rewarding things to do with our wikilife ;-) Fram (talk) 10:31, 13 October 2014 (UTC)

I'm not checking anymore VE edits, this problem is picked up by WP:WCW which detects categories before the end of the article. It seems totally useless to check VE edits as the VE team doesn't seem to be very interested in bug reports... --NicoV ^{(Talk on frwiki)} 12:57, 13 October 2014 (UTC)

I've filed this as a bug against Parsoid, because I think that's where the problem is, and I couldn't find the original bug number. Whatamidoing (WMF) (talk) 18:54, 14 October 2014 (UTC)

Editing notes results in an odd preview.

Tracked in Phabricator
Task T74045

This edit where I attempted to add a space before the last word, caused an odd preview to show up in VE (also the VE automatically inserted spaces for the group parameter and value, not sure if that's intentional though I don't think it matters). You can see the before/after here. Also entering edit mode (from the top of a page, not a section) jumps me down to the references list and hides the infobox (not sure why either of those happen). Protonk (talk) 19:33, 12 October 2014 (UTC)

Also this is on chrome stable on a mac. If you want me to fill out a bug template I can, but I figured I'd ask here to see if it had been seen before and if it hadn't I can go and file a bug on bugzilla myself. Protonk (talk) 23:00, 12 October 2014 (UTC)

Parser functions (the #tag: system used in that line) are not supported at all (yet), so the fact that a bug has been found is not altogether surprising. I wonder if it's related to T74006. Whatamidoing (WMF) (talk) 18:19, 14 October 2014 (UTC)

Thanks for posting it there. It's marked as a dupe of T51784. Protonk (talk) 20:46, 14 October 2014 (UTC)

Manage TemplateData

Tracked in Phabricator
Task T71149

I've just had to clear up a number of edits where people have added template data in the wrong place. Template:Roman_Catholic_Cathedrals_in_Great_Britain_and_Ireland, Template:Punknews, Template:List_of_Philippine_seas Template:ABC_Mindanao plus a few others. These edits left about 100 main space article displaying templateData sections, a list of affected articles was at [24] I've fixed all the problems now.

This is new behaviour and the cause seem to be the Manage TemplateData button. If you edit a template and quite reasonably click the button, and go through the dialogue, then it will add a template data section at the end of the article. This is bad behaviour as template data should either go in a <noinclude> section or in the /doc subpage.

I think the button needs some more smarts. If not in a subpage it should ensure that the section is inside <noinclude>.

I not quite sure about the Manage TemplateData button overall. It makes it too easy for users just to create meaningless templatedata sections. Witness the number of sections in the above diffs where the user has just taken the defaults and not added any actual documentation.--Salix alba (talk): 15:57, 5 October 2014 (UTC)

The button is very helpful. Possibly it should insist that at least 5 boxes or some percentage of the boxes are filled in, and show a warning if you save meaningless data. User:GKFX^talk 16:16, 8 October 2014 (UTC)

I just talked to James F about this, and he's going to have TemplateData wrapped in noinclude tags when it is added to non-subpages in the Template namespace. Look for this improvement two weeks from today. Eventually, TemplateData will probably be added to its own namespace, at which point the tool can be re-written to use that namespace exclusively.

BTW, the TemplateData GUI is going to appear on about 30 more Wikipedias in about an hour. The other problem that I expect to see more of is people accidentally creating two blocks of TemplateData. It's one block per template, no matter how many subpages are present; all except the last will be ignored. Whatamidoing (WMF) (talk) 16:58, 9 October 2014 (UTC)

@Whatamidoing (WMF): If a block of TemplateData already exists, then the software really should prevent a second block from being created, yes? Or, at minimum, require the user to affirmatively say he/she wants to create a new block even though one already exists. -- John Broughton (♫♫) 15:44, 14 October 2014 (UTC)

Ideally, the world would be that simple. But there's no way for the TemplateData editor to tell which pages need to be checked. When there is already a TemplateData block on {{Foo}}, a human can figure out that it's okay to add a TemplateData block to {{Foo/sandbox}} but not to {{Foo/doc}}. The editing tool can't infer from the file names (or from greater knowledge of how the various pages are meant to interact) when possibly-related pages should have the same or separate TemplateData. Whatamidoing (WMF) (talk) 18:09, 14 October 2014 (UTC)

Tracked in Phabricator
Task T74062

It should be possible to at least issue a warning if another page with the same base name has template data. You can use easily use an api call [25] to find which pages have template data.

p.s. Another instance of the bug[26]--Salix alba (talk): 22:10, 14 October 2014 (UTC)

I've reported this idea as T74062, separate from the earlier one. Whatamidoing (WMF) (talk) 22:25, 14 October 2014 (UTC)

Adding infoboxes is painful

Tracked in Phabricator
Task T74083

I wanted to add {{Infobox musical artist}} to an article and it proved to be much more painful than it needs to be.

If you want add one of the minor fields like {{{genre}}} you have to

Click on Add more information
Click on Show 17 more fields
scroll down to find the field you want and click on it
The window will then scroll to the top of the form so you have to
scroll down again to find the field you want and fill in the value
repeat the whole process again.

This could be made easier. Why do I need to click twice to show all fields? Why do I need to go back to square one after adding a field? Why does it not auto scroll to the correct place (actually why not simply show the field under it description in the list of fields).--Salix alba (talk): 22:24, 14 October 2014 (UTC)

You can also search for the parameter, if you know its name.

I think that particular infobox needs its TemplateData adjusted (why aren't the most common fields 'suggested'?), but your suggestion is a great one, and would solve this annoyance. It's T74083 now. Whatamidoing (WMF) (talk) 17:49, 15 October 2014 (UTC)

Possible Bug

Tracked in Phabricator
Task T45026

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	I was tidying up some of the language in Krzysztof Ignaczak.
Steps to Reproduce:	Opened Krzysztof Ignaczak in VE, saw strange line spacing. When selected these lines were bordered by dashed lines. I deleted them, not seeing that they were attached to anything.
Results:	Accidental deletion of images.
Expectations:	Some note to say what the dashed lines mean.
Page where the issue occurs	www.wikipedia.org
Web browser	Firefox
Operating system	Ubuntu
Skin
Notes:
Workaround or suggested solution	None, I just reverted my edit and then re-did the language changes I wanted to make.

Hi, and thanks for this note. I'm sorry you had this problem.

This is a design problem that the VisualEditor team has been worrying at for a long time, with no perfect solution on the horizon yet. What you deleted are called "slugs", which are sort of placeholders. Without them, it would be difficult to add something before the first paragraph or between some kinds of items. But when the code for the image is "up here" and the image displays "down there", there's no easy way to tell that you've selected both (unless you scroll up and down through the whole article every time you click on something, and nobody's going to do that). Whatamidoing (WMF) (talk) 20:47, 16 October 2014 (UTC)

No way to add a title to an external link with no title

Tracked in Phabricator
Task T74150

I can not find anyway to add a title to an existing bare link that has none without having to make a new link then delete the old. Further confusing the matter the new link UI that initially appears seems to force creating a link a another wiki article. At least that was my first impression of it. Phatom87 ^{(talk • contribs)} 17:23, 16 October 2014 (UTC)

I can't figure out how to do that, either. It's now T74150. Support for these bare, auto-numbered links is a new thing, and lcearly there's still some work to go. With luck, James F will come around and tell us how to do it, or at least assign the bug to one of the devs. Whatamidoing (WMF) (talk) 20:57, 16 October 2014 (UTC)

User:Phatom87, your userpage says you're using Mozilla. Can you tell me your OS and web browser version? Whatamidoing (WMF) (talk) 15:21, 17 October 2014 (UTC)

Whatamidoing (WMF) browser version is 32.0.3. The OS linux running kde 4.14.1. Phatom87 ^{(talk • contribs)} 21:40, 17 October 2014 (UTC)

The type of link I have issues with is one written as http://example.com which shows up as textual url. Auto numbered links seem to function as expected for me. User:Phatom87/sandbox has an example of both forms. The original edit I was trying to make involved an external link where the title and corresponding link had simply been written one after the other.Phatom87 ^{(talk • contribs)} 21:54, 17 October 2014 (UTC)

Next question: how are you opening the link dialog? Right now, it appears that we're getting different responses based on which of the (three) different methods you use. (I mostly use Command-K, but there's the button on the toolbar and also you can click the tab underneath the link that shows what the link goes to). Whatamidoing (WMF) (talk) 01:59, 18 October 2014 (UTC)

Whatamidoing (WMF) I have been using the tab that shows up after clicking on the link.Phatom87 ^{(talk • contribs)} 01:27, 19 October 2014 (UTC)

External links in refs become redlinks in VE?

Tracked in Phabricator
Task T74251

Why do the external links in the references become redlinks in VE? E.g. in Derik, Turkey. The same happens with the website in the infobox, but not with the external link. I don't remember this happening before this update. Fram (talk) 18:30, 23 October 2014 (UTC)

This regression appeared last week. The patch has already been merged and will probably appear here with next week's update. Whatamidoing (WMF) (talk) 22:10, 23 October 2014 (UTC)

Wrong reference numbers in article text

Tracked in Phabricator
Task T52474

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	Editing article references
Steps to Reproduce:	Compare the article in VE edit mode and normal read mode.
Results:	(1) ref #1 in first lead para should actually be numbered ref #2 (there is 1 recognized ref in the infobox). (2) numbers of "sfn" citations are OK, but "ref" citations are counted separately, a good example is in section "Bohemia", the last 3 refs are numbered #5-#7 (they are the 6th-8th "ref" citation in the article, see point 1 for the -1 difference), however the correct numbers are #34-#36 considering all references.
Expectations:	Reference numbers in "read" and "VE beta" modes should all be the same
Page where the issue occurs	https://wiki.riteme.site/wiki/Otto_I,_Holy_Roman_Emperor
Web browser	Firefox 32.0.3
Operating system	Windows XP
Skin	Vector
Notes:	Reference numbering in the final "reflist" are all OK, the wrong numbering affects only the single reference numbers in the main text.
Workaround or suggested solution	Use source editor for references.

GermanJoe (talk) 22:54, 14 October 2014 (UTC)

This is a known problem. I don't think anyone's working on it during this (two-week) sprint, so it almost certainly won't be fixed this month. If it were just a problem with the numbering, it'd be annoying but not such a big deal. However, it also prevents you from re-using the first (infobox) reference, which is even worse than having scrambled numbers. Whatamidoing (WMF) (talk) 17:40, 15 October 2014 (UTC)

Could you ping the responsible developer(s) again? The problem is now 15 months old and the latest meaningful post was 12 months ago. I realize, it's a complex issue - but is there any idea, how to solve this problem? And when (approximately)? Thank you. GermanJoe (talk) 18:11, 15 October 2014 (UTC)

Sure, let me see whom I can find today. Whatamidoing (WMF) (talk) 20:17, 16 October 2014 (UTC)

@Whatamidoing (WMF): Have you found out anything new about this problem's status yet? GermanJoe (talk) 18:41, 23 October 2014 (UTC)

Unfortunately, I have no news. In this case, no news probably means that it will not be fixed any time soon. :-( Whatamidoing (WMF) (talk) 21:59, 23 October 2014 (UTC)

Referencing - along with text editing, images, templates, links and tables - is one of the core functions of article editing. I am not talking about "perfect" here, but the editor absolutely needs to provide all core functions without mayor bugs. Back to the source editor for such tasks, i guess. Thanks for the information. GermanJoe (talk) 11:40, 24 October 2014 (UTC)

User guide

I've reverted the creation of a new version of the user guide. While it had improvements, it also removed topics that are useful, had missing images, and didn't reflect the situation at enwiki (e.g. saying that you get "edit" and "edit source", while here you get since more than a year "edit source" and "edit beta").

The user guide needs an update, but it shouldn't be used to remove all mentions of problems or to introduce new inaccuracies. Fram (talk) 18:18, 23 October 2014 (UTC)

I apologize for the typo on the one file link, which caused it to render as a redlink instead of as an image.

Speaking of images, it looks like only four of the 70 images show the "Edit" button, and it would have been pretty easy to replace those with screenshots specific to the English Wikipedia, if you had wanted to have 100% of the images look like the local implementation, rather than only 94%. It seems to me that 94% accuracy would be preferable to what you've restored, which has problems with about a quarter of the images. I count exactly two instances of "Edit" rather than "Edit beta" in the text. It seems that this would have also been very easy to address, by typing the word beta twice on the page, if you had wanted it to reflect the local situation more precisely.

Can you tell me what was useful topics were removed? I'm sure that User:John Broughton, who wrote most of this, will be very interested in hearing what was omitted. Whatamidoing (WMF) (talk) 22:26, 23 October 2014 (UTC)

E.g. the complete intro (how to enable VE? Seems rather important information for a VE user guide...). And also "What VisualEditor can't be used for", completely omitted in the new version, even though there clearly are still quite some things it can't be used for. There may be more, that would require a line-by-line comparison, but this should suffice. Feel free to update the user guide and correct the currently incorrect images, "it would have been pretty easy to replace those with screenshots" anyway. Fram (talk) 04:32, 24 October 2014 (UTC)

So that the text doesn't match the pictures? That's not going to help people as much as having both the correct text and the correct image.

The section on what VisualEditor can't be used for is at least half wrong. You can use VisualEditor for hidden text, image galleries, mathematical formulae, etc.

Thanks for the specific feedback. It should be easy to accomodate your concerns, since you explained them. Whatamidoing (WMF) (talk) 16:27, 24 October 2014 (UTC)

@Whatamidoing (WMF) and Fram: The VE user guide at wiki.riteme.site was, at one point, intended to warn users of more noticable issues and shortcomings of VE, as well as to explain the functionality that then existed. A lot has changed since I personally last edited it in November 2013, working with Maggie Dennis/

The VE user guide at mediawiki, which I helped update in August 2014, is intended to be translated into lots of languages. So - I think - it makes less sense to lengthen it by describing issues or missing functionality; that's more work for translators, and work that - presumably - will have a relatively short useful life.

Unfortunately for the en.wikipedia version, it's less than optimal to do either of the easy things: Leave the outdated version as is, because it has more content, or overwrite it with the mediawiki version, losing material the additional material that is still relevant (some will not be, of course).

The ideal thing, obviously, would be for someone to go through the overwritten version and pull out what disappeared but is still valuable. That person isn't me. I'll be happy to get involved in revising the user guide after the English language Wikipedia community agrees that VE is ready to be the default, or if we can get agreement on the "pain points" that will be fixed in order for VE to become the default. Until then, I think my time is better spent elsewhere. -- John Broughton (♫♫) 00:23, 28 October 2014 (UTC)

Old list

This is a list of suggestions and bug reports from Fram that were archived before getting associated with bug numbers:

Categories: a much too small drop down menu
Tracked in Phabricator
Task T71574
box isn't resizable (general problem, mentioned here in conjunction with the previous one
Tracked in Phabricator
Task T51969
You can add a sortkey to individual categories, but it isn't recorded (not when adding a category and not afterwards)
Tracked in Phabricator
Task T74168
Advanced settings. The first two, "Let this page be indexed by search engines" and "Show a tab on this page to add a new section" are as far as I know never used on articles. Can these be namespace-specific so that they aren't shown on articles (the main target of VE)?
Tracked in Phabricator
Task T74396
Page settings vs. advanced settings: Page settings should be the common three "redirect", "disambiguate", and "displaytitle"; all the others are very rarely used and should be "advanced" or not displayed at all (as mentioned above).
Tracked in Phabricator
Task T74397
Categories should be the first among the options as it is the most commonly used of these options
Tracked in Phabricator
Task T74399
it makes no sense to have a dropdown with "options", "page settings", and so on, if the options then simply list the others ("page settings" and so on) again. Either remove options and only keep the other ones (in the order as described above), or only have "options" and "switch to source editing" and discard the rest in this dropdown.
Tracked in Phabricator
Task T71451
Why do the dropdown menus on the left have a dropdown arrow, but not those on the right?
- The Help "menu" is technically a button, not a menu, even though I doubt that anyone except the devs can tell the difference. The icon used for the Page options menu is, itself, a common icon for menus on the web, so a drop down arrow would be redundant. (Try doing an image search for "menu button three lines".) James F is planning to re-work the toolbar, so all of this may change later. Whatamidoing (WMF) (talk)
When I open a template, I can select the template name (in "show options" mode) and remove it (trash can icon). But I can't apply the change. Seems strange, this is a nice way to remove templates (e.g. hidden ones).
- If you can select it (and therefore if you can open it in the template dialog), then you can delete it much faster by using the delete/backspace key on your keyboard. Whatamidoing (WMF) (talk)
Add a "basic cite" (or open an existing one), drop-down the "use this group", and you get the upper half of the text "general references". If you get multiple groups, like on William Shakespeare, then you can't even see the other groups.
- I can't reproduce this. Is it still a problem? If it's still a problem, does it depend on your font size/zoom level? Whatamidoing (WMF) (talk)
William Shakespeare: I tried to open the references section in VE, but then the script just kept hanging.
Tracked in Phabricator
Task T74401
Lakeland School District, Pennsylvania. Open in VE, scroll to "Eight grade", PSSA results. Change the results? You get a template box, with a lot of col templates. Go through them on the left (click "col-begin", "content", and so on), and you see the cursor move down on the right side. Go through all the fields in this way. What do you get? Nothing! Is the content missing? No, it is only invisible, you need to actually click inside the right-side content boxes. Try it with the first one! Oh, right, that one's empty…
Tracked in Phabricator
Task T67356
Wikitext in TemplateData descriptions doesn't work, see e.g. the description of ref list
Tracked in Phabricator
Task T53311

Most of the bugs were known. Whatamidoing (WMF) (talk) 17:47, 24 October 2014 (UTC)

Thanks. Problem 10 indeed doesn't seem to happen anymore. Issue 9, while your answer is technically correct, it doesn't really address the issue. You shouldn't be able to make changes anywhere which are not saved / implemented, but not indicated as being skipped either. User:Jdforrester (WMF)'s reply to 72397 is particularly unhelpful (I love it how he now wants data to prove this, something that has never bothered him when the WMF implemented or developed anything, like the image functions), and could perhaps be better asked here if he wants an answer and doesn't just want to complain for the sake of it. Anyway, if he has any examples of "encyclopedia article editors" (the group the bug is about, as described in the opening post) that need the other options with any regularity on articles, he is free to provide the data. I'll show my evidence of all examples I have found where these are used in VE edits. Right, nowhere.... I have never seen an article with the "Disable the edit links next to each heading on this page." function used. It probably exists, somewhere, for some reason, but this seems to be something that is perhaps used on Mediawiki, or on non-article pages, but not on articles (and sandboxes), which are 99% of VE's edits here. Fram (talk) 21:09, 24 October 2014 (UTC)

If it were up to me, then "disable section editing" (which I've seen used at Meta) would not exist at all, and therefore there would be no need for the item to exist.

I'm glad that problem #10 is solved. I know when you posted it originally that I managed to get it to happen once out of about five attempts, but I couldn't do it this week. If it reappears, let me know.

I'm not sure that I understand what you've said about #9. Isn't the refusal to let you "apply changes" a pretty clear indication that your change has been skipped/rejected? Whatamidoing (WMF) (talk) 00:51, 25 October 2014 (UTC)

I'm not sure I understand what I said about #9 either, I seem to have been mixing up a few things. I agree about disable section editing. Fram (talk) 12:06, 25 October 2014 (UTC)

I could always file a bug to have __NOEDITSECTION__ killed.

Whatamidoing (WMF) (talk) 17:41, 28 October 2014 (UTC)

Not obvious how to cancel editing

Would be good to have a cancel button next to the save changes button so that you can easily cancel editing and switch back to the last view (typically reading view). Ryanseys (talk) 03:54, 27 October 2014 (UTC)

Hi Ryanseys,

Thanks for this note. Several people have made this suggestion recently.

It was removed a few months ago because no one seemed to use it, and the toolbar was getting too crowded for people with normal-size screens, especially if they have to zoom in for WP:ACCESS/vision reasons. (When it doesn't all fit, it wraps into two bars, and if you're working on, say, an 11-inch MacBook Air, that's almost half your screen.)

How often do you use the Cancel link in the wikitext editor? Do you think you'd use it about the same amount in VisualEditor? (Everyone is welcome to answer these questions.)

By the way, you can cancel your edit by doing anything that takes you to a new page. Closing the browser tab, clicking the 'Read' link, or hitting the "back" button on your web browser will all cancel the edit/lose your work. Most web browsers will ask you to confirm (so you don't accidentally lose your work if you click the wrong button). Whatamidoing (WMF) (talk) 17:47, 28 October 2014 (UTC)

Copy/paste in VE followed by adjacent delete

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	I was moving some text with copy paste and then continuing with normal editing, including using the delete key.
Steps to Reproduce:	The following keystrokes reproduce the problem for me. View Cosmic Stories and Stirring Science Stories. Alt-Shift-V to edit; double click the word "pulp" in the first line to select it (and the following space) and press Ctr-C to copy it. Click after the end of the word "science" directly following and press Ctrl-V; this pastes in "pulp ". There should now be two spaces after the word "pulp" and the cursor should be between the two spaces. Press backspace, and the word "pulp" is duplicated; the result looks like this: "two pulp sciencepulppulp fiction". Note this does not seem to happen if you do anything else after the Ctrl-V except press backspace; once you move the cursor it appears to clean itself up and the error can't be reproduced. A more dramatic result happens if, after the Ctrl-V, and before doing anything else, you click after the final "e" of "science" again. This causes the word "pulp" to be pasted over and over again; I let it go for thirty or forty iterations to see if it would stop and it didn't.
Results:	See above for the results.
Expectations:	I expected the delete and mouse-click to do what they normally do.
Page where the issue occurs	N/A
Web browser	Chrome 37.0.2062.124 m
Operating system	Windows 7
Skin	Vector
Notes:	N/A
Workaround or suggested solution	Click anywhere else first and the problem doesn't happen.

Mike Christie (talk - contribs - library) 12:10, 25 October 2014 (UTC)

The error can be reproduced in FF 32.0.3 (Windows XP). The infinite repetition also happens, when you click in a later blue link (try left clicking on "F. Orlin Tremaine" in the 4th line after Ctrl+V). GermanJoe (talk) 13:51, 25 October 2014 (UTC)

I was looking around WP:fr to see if this bug was already reported: I confirm this with Safari 7.1 Mac OS X 10.9 (a weakened form can be seen with: select a word => Ctrl+C => Ctrl+V => Ctrl+V) - Drongou (talk) 23:32, 25 October 2014 (UTC)

Mike Christie, GermanJoe, Drongou, can any of you reproduce this bug today?

This was driving me nuts last night (for me, all it took was copy plain old text, paste it, and wait a few seconds), and I emailed James F about it. This morning, when I wanted to double-check the minimum requirements for the bug report, I couldn't get it to happen. I doubt that a fix was pushed out that fast. Whatamidoing (WMF) (talk) 17:35, 28 October 2014 (UTC)

I can't reproduce it any more either. Any idea what could have happened? Mike Christie (talk - contribs - library) 18:15, 28 October 2014 (UTC)

It's the same for me. Now I'm using Safari 8.0 Mac OS X 10.10. It was very easy to reproduce but can't do it anymore. - Drongou (talk) 22:48, 28 October 2014 (UTC)

Me neither. Looks fine for now. GermanJoe (talk) 17:28, 29 October 2014 (UTC)

Excellent. Apparently the patch went quickly, without waiting for the usual deployment train.

By the way, updates are now on Wednesdays for the Wikipedias (still Thursdays for MediaWiki), and the annoying red links bug (infoboxes and other templates showed red for external links) was fixed here about four hours ago. Whatamidoing (WMF) (talk) 22:36, 29 October 2014 (UTC)

Adding to lists

I don't know if this is a bug or just my ignorance, but I can't figure out how to add items to lists, as in List of fiction set in Berlin. I can do it using the regular editor, but that is one of the things that it is cumbersome for using (lots of pipes and dashes). Kdammers (talk) 06:38, 30 October 2014 (UTC)

Table editing is one of the main problem areas of VE. Basically, at the moment, you can't add anything. Fram (talk) 07:53, 30 October 2014 (UTC)

Well, you can't add anything reliably; every now and again, if you manage to click in exactly the right places, you can copy and paste rows of tables, and then replace their contents with what you want.

I recommend waiting two or three weeks, until the first basic table editing tools appear here. You can test it now at https://en.wikipedia.beta.wmflabs.org/wiki/Sandbox The first version just went up today. It's got a ways to go, but you should (if Beta Labs as a whole hasn't fallen over again, which happens a lot) be able to insert a table and add rows and columns to existing tables. (The list of what you can't do yet, or that only works on certain browsers, is too long to bother with: just assume that almost everything else won't work today.) Whatamidoing (WMF) (talk) 17:56, 30 October 2014 (UTC)

SUBSTed defaults in templates

Tracked in Phabricator
Task T4700

See this diff; a set of SUBST values came up for the URL access date, so presumably someone has set up the default values for this template. I wasn't sure if it would work so I tried saving it, but it didn't subst. I'm no template guru; can someone else tell me if this was set up incorrectly? Mike Christie (talk - contribs - library) 10:04, 30 October 2014 (UTC)

James F says that it should not be possible for {{subst:example}} to be saved in wikitext (without nowikis). However, there is this very old bug that prevents subst:ing inside any kind of <tag> that belongs to a MediaWiki extension (<ref> tags and <gallery> tags, maybe <math>?). He's putting it on his list of things that need to be fixed about wikitext. In the meantime, I'll pull the TemplateData from cite web and cite news, and some admin or templateeditor will have to make another null edit on those templates. Whatamidoing (WMF) (talk) 18:26, 30 October 2014 (UTC)

Template:Citation needed span

If Template:Citation needed span is used in an article, it is very cumbersome to remove the citation (for say, if you now have a source) without removing the text needing attribution. The text is melded into the template using the "text" parameter, so deleting the template deletes the text. Is there a way to extract the text without opening up the template parameters, cutting or copying the text out, and pasting the text back into the article?--¿3family6 _contribs 02:22, 28 October 2014 (UTC)

No, there isn't. That template was designed to be convenient in wikitext, a couple of years before VisualEditor was available to anyone. If you wanted it to be convenient to use in VisualEditor, you'd have to completely re-design the template. Whatamidoing (WMF) (talk) 17:25, 28 October 2014 (UTC)

I don't use the template at all. But another editor who frequents many of the same pages as myself, does. When VE is finally rolled out as default, can the use of wiki-text specific templates be discouraged?--¿3family6 _contribs 04:15, 30 October 2014 (UTC)

Whether to encourage or discourage any particular templates is up to the community, not to the WMF. Whatamidoing (WMF) (talk) 17:49, 30 October 2014 (UTC)

That's not the only marking template which may sometimes be replaced by its first parameter. (I'm thinking {{math}} or {{nowrap}}.) A VE method of replacing a template by its first (unnamed) parameter might be helpful. A VE method of wrapping a template around selected text might also be helpful. — Arthur Rubin (talk) 15:43, 1 November 2014 (UTC)

This would be an extension, not a bug fix. And I don't consider it a show-stopper, although there are still quite a few bugs which are show-stoppers as far as I'm concerned. — Arthur Rubin (talk) 15:49, 1 November 2014 (UTC)

I like this idea. Selecting text and choosing "convert to template", then picking a template from a pick list, could put that text in a field of that template, with the target field perhaps to be identified via templatedata. Similarly, choosing "convert to text" when editing a template could take that same field and put it in place of the template. I'm not sure how broadly useful this would be but the cases Arthur mentions above seem likely to benefit. Mike Christie (talk - contribs - library) 15:51, 1 November 2014 (UTC)

As an alternative question, how could one get the functionality of {{citation needed span}} in VE-friendly templates. The only way I can think of is to have {{citation needed start}} and {{citation needed end}} be visible in VE, while the first wouldn't be visible in normal text display. Is that possible? Would this work with PARSOID? — Arthur Rubin (talk) 16:03, 1 November 2014 (UTC)

Making 'invisible' templates become visible is already on the list. There are a lot of invisible templates and functions (persondata, use dmy dates, etc.) that people need to be able to edit and/or remove, and the current method ("Place your cursor in the general area of the page that you'd expect to find the wikitext for the template in. Slowly press the cursor key, moving one character at a time, until the template happens to light up") is not good. I assume that the "visibility" will look like the gray (!) icons for HTML comments. I'm not sure how they'll determine that the template is invisible, though. Maybe Parsoid knows, and can tell VisualEditor? In the worst-case scenario, I suppose we could add a line to TemplateData that says "I'm invisible". Whatamidoing (WMF) (talk) 17:49, 1 November 2014 (UTC)

Unnecessary succession of nowiki

Tracked in Phabricator
Task T74844

In this edit, not only VE added as usual nowiki tags around a whole sentence to escape a single quote, but it also added several nowiki one after an other <nowiki>...</nowiki><nowiki/>. --NicoV ^{(Talk on frwiki)} 17:50, 30 October 2014 (UTC)

How to record the wikitext is Parsoid's choice; maybe User:SSastry (WMF) would be able to provide more information. I see three sets of nowiki tags. The goal was apparently to have "Netflix", except with single qoutation marks instead of doubles. What's your preferred method of doing this in wikitext? Whatamidoing (WMF) (talk) 19:23, 30 October 2014 (UTC)

Whatamidoing (WMF) No, there are 4 sets of nowiki tags:

The first one is a combination of an opening tag and a closing tag <nowiki>...</nowiki>.
The second one is a self-closing nowiki tag <nowiki/> (just after the previous set) : it's totally useless, and brings nothing except more complexity to the wikitext
The third one is a self-closing nowiki tag <nowiki/> (just before the next set) : same remark as above
The fourth one is a combination of an opening tag and a closing tag <nowiki>...</nowiki>.

My report is that 2 sets are completely useless (first and second are redundant; third and fourth are redundant).

Of course, there's also the problem reported many times, a long time ago, that if nowiki are added they should be added only around the part that needs them not around a whole part of a sentence, but it was not the main issue I was reporting. For this, as it already been said so many times, my preferred methods (in order):

Use {{'}} (it should be possible to configure VE on each wiki to know if there's such a template, that's what I'm doing for example in WPCleaner's configuration)
Use '<nowiki/>'' (nowiki between the single quote and the italic formatting)
Use <nowiki>'</nowiki>'' (nowiki around the single quote)

--NicoV ^{(Talk on frwiki)} 23:41, 30 October 2014 (UTC)

You're right; there are four there:

<nowiki> MARVEL Studios et ABC prépare cinq séries '</nowiki><nowiki/>''Netflix Original''<nowiki/><nowiki>' de </nowiki>super-héros exclusivement pour la plateforme Netflix.

I may not have been clear about how this works. VisualEditor does not choose the wikitext. Parsoid chooses the wikitext. You can't "configure VE" to do something that Parsoid is doing. That's why I asked Ssastry to look at this: the Editing team can't fix it.

Furthermore, as I'm sure I've mentioned before, the devs have decided that depending on local templates (which may be missing or vandalized, and which would definitely add to complexity for both configuration, and in this case, confusion for editors who see a plain ' but who get a template dialog when they select it) is poor design, and they refuse to do it. The proposal to {{'}} has already been rejected, and even if they had accepted it, they'd still need a solution for the hundreds of wikis that do not have that template. Either of your other two approaches would work perfectly, and I think that's what should have been done here. If I were trying to get this effect in wikitext (single quotations marks around an italicized word), I think I'd probably try something like this: ''<nowiki>'</nowiki>Netflix''', but that's actually bad form (I'm exploiting an unintentional behavior in the wikitext parser that could be removed at any time), and can only be done if you want the single quotation marks to be italicized as well. It would be better to wrap both of the desired single quotation marks in nowikis. Whatamidoing (WMF) (talk) 17:58, 31 October 2014 (UTC)

Okay, I'll file a bug report with this info and we'll take a look at improving some of this. At least couple of the back-to-back nowikis should be fixable -- those look like malfunctioning heuristics. But, optimal nowiki placement while dealing with quote characters is a hard problem in general. SSastry (WMF) (talk) 03:02, 1 November 2014 (UTC)

SSastry (WMF), thanks for the bug report and the work on it. Just a thought for improving the nowiki placement (I don't know if my suggestion is feasible, easy, ...): when you want to add a <nowiki>...</nowiki> around a sentence, would it be possible to first check if using only <nowiki/> at the beginning / at the end of the sentence works for escaping ? --NicoV ^{(Talk on frwiki)} 15:09, 5 November 2014 (UTC)

Nico, yes, that might work for quote scenarios which is what I presume you are asking about. SSastry (WMF) (talk) 15:44, 5 November 2014 (UTC)

~~Here's another instance of a useless nowiki tag, I can't see any justifiable reason why it would even appear here.~~ -- intgr [talk] 14:10, 3 November 2014 (UTC)

This one is probably because there's no space between the internal link "NIST" and the word "as". --NicoV ^{(Talk on frwiki)} 14:42, 3 November 2014 (UTC)

Ahh, sorry, my bad. -- intgr [talk] 18:00, 3 November 2014 (UTC)

Edit conflicts destroying work in VE

When I tried to edit Anomaly (Lecrae album), this edit by another user (involving the citation needed span template I complained about above) created an edit conflict. I ended up losing all my work and had to try again. Is there a way in VE to preserve edits in a cache like you can with wiki-text? I'm using the latest version of Firefox on Windows 8.1, if that is any help.--¿3family6 _contribs 04:21, 30 October 2014 (UTC)

That looks like a great example of why we need to encourage section editing and enable it in V/E. A large proportion of edit conflicts could be avoided if various won't fix bugs were resolved, but even if we could get IT resource to make the system less bitey by reducing edit conflicts, I think this would be a tricky one. Ϣere SpielChequers 05:42, 30 October 2014 (UTC)

Per a recent discussion, section editing would not help, because detection of edit conflicts is handled by Mediawiki, and it's irrelevant whether the edits were done by VE or wikitext. I don't know how VE reacts when there is an edit conflict, so there may be a problem that can be fixed there, but section editing wouldn't make any difference. Mike Christie (talk - contribs - library) 09:19, 30 October 2014 (UTC)

There are a few closed bug related to this. In bug T52753 JDF recommends that when you get an edit conflict you switch to the wikitext editor and resolve the conflict there. Per bug T71150 there should be a "Resolve conflict button". You can see other related bugs at bugzilla search.--Salix alba (talk): 23:57, 30 October 2014 (UTC)

3family6, I'm a little confused about what happened here. When you save, it should say that there is an edit conflict. Then there is a green button that says "Resolve conflict" (where the "Save page" button used to be), and you go to the regular wikitext edit conflict window and resolve it. Did this not work for you? Whatamidoing (WMF) (talk) 17:58, 1 November 2014 (UTC)

I don't remember well what happened. I think I clicked that button, but my edits were missing and all I had was the article pre-revision.--¿3family6 _contribs 19:08, 1 November 2014 (UTC)

The edit conflict window is the same one that's used for the wikitext editor. The other person's version is shown first, then a diff showing their changes contrasted with yours, and finally another edit window that is your changes (the ones that will be lost if you don't resolve the edit window). I think that the WMF needs to think about improving edit conflicts in general. I would like to see far fewer of these in my everyday editing. Whatamidoing (WMF) (talk) 18:05, 5 November 2014 (UTC)

Error message when using VE to edit sandbox

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	Edit my User page sandbox, where I'm developing an article.
Steps to Reproduce:	Click edit beta. Error message pops up. It asks to retry. If I click okay, the message pops up again, ad infinitum. If I click cancel, the box closes, and I can't edit the page.
Results:
Expectations:
Page where the issue occurs
Web browser	Firefox 33.0.2
Operating system	Windows 8.1
Skin
Notes:	I tried to copy-paste the error to here, but I could only highlight the error code, not copy it.
Workaround or suggested solution	Unsure. I can now edit my sandbox without any problem.

¿3family6 _contribs 21:28, 5 November 2014 (UTC)

I couldn't replicate this, editing User:3family6/sandbox (or my own sandbox, for that matter). (Using MacOS, Firefox, both latest versions). -- John Broughton (♫♫)

Odd Error Message Editing Patrícia Ferreira

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	Open the page in VE to add information.
Steps to Reproduce:	Pressed the 'edit this page' tab.
Results:	Got this error message - https://commons.wikimedia.org/wiki/File:Capture.png (I would have copied it but the error message wouldn't let me copy it) The odd thing was that the page opened fine when I pressed 'okay'.
Expectations:	What were your expectations instead?
Page where the issue occurs	https://wiki.riteme.site/wiki/Patr%C3%ADcia_Ferreira
Web browser	Chrome
Operating system	What's your OS?
Skin	Monobook/Vector?
Notes:	Any additional information. Can you provide a screenshot, if relevant?
Workaround or suggested solution	N/A

Red Fiona (talk) 22:20, 5 November 2014 (UTC)

That is exactly the same error I articulated in the bug report listed immediately above this one.--¿3family6 _contribs 22:40, 5 November 2014 (UTC)

Sorry about that. It's interesting that the page wouldn't open for you but would for me. Red Fiona (talk) 23:17, 5 November 2014 (UTC)

Red Fiona, are you also using Windows 8? Your reports are about an hour apart. Is everything working normally now? Whatamidoing (WMF) (talk) 23:47, 6 November 2014 (UTC)

Yes, also on Windows 8. Everything worked fine today :) Red Fiona (talk) 00:56, 7 November 2014 (UTC)

Slow in chrome

Visualeditor is a bit slow to save pages in Chrome (a popular browser). I think we should fix this before it is released to the general public. Thanks!Pcfan500 (talk) 11:14, 7 November 2014 (UTC)

Hi Pcfan500,

Thanks for your note. I'm sorry you had a problem with save speed. Saving pages depends on a lot of things that VisualEditor has no control over, like the number of people editing Wikipedia at the same time and the quality of your (upstream) internet connection. On average, most editors say that saving average-length pages isn't usually too bad. Long pages, like Bangkok, normally take a long time under the best of circumstances. And if you combine a long article with the whole cluster being unusually busy, it can be painfully slow—well over a minute some times. The devs have been working on improving save performance. I believe that the most recent thing they did for performance didn't make much difference in practice. (Normal people don't notice tenth-of-a-second improvements, even if the devs can prove that it is technically faster. ;-) They're going to keep working on this. I believe that the product manager would like to see all pages saving in less than 15 seconds. I hope that he gets what he wants.

By the way, VisualEditor is already being used by thousands of editors around the world. It is available by default at more than 150 or so Wikipedias, for both logged-in and logged-out users. It's also in use at some private wikis (like businesses that have internal wikis). Whatamidoing (WMF) (talk) 19:47, 7 November 2014 (UTC)

@Pcfan500: It would be really helpful to know (a) what page or pages you were editing when you experienced slow saving, and (b) roughly how long it took to save a specific edit. Of course it's difficult to estimate relatively small durations of time (a few seconds), but even a rough number is helpful. (Saying "thousand-one", "thousand-two", "thousand-three", etc., under your breath, or aloud, is close enough to one-second intervals to be fairly accurate.) -- John Broughton (♫♫) 00:50, 9 November 2014 (UTC)

ISBN link in cite-book shows as a Redlink

Tracked in Phabricator
Task T75320

I just added an ISBN to an existing book reference using the Cite-Book template-editing widget in the Visual Editor. When I saved the edit it worked correctly (yay!) but while still in editing mode the ISBN part of the footnote was a redlink. This makes it appear that the information has not been inserted correctly (I even went to check that ISBN in Special:Book sources before saving just in case it was broken somehow.

In short - validly input template links shouldn't show as red in the editing mode if, when saved, they actually go blue. Witty lama 10:52, 10 November 2014 (UTC)

Thanks for the note. Previously, all links inside templates showed blue, even if they didn't exist. They fixed that, but overcorrected, and we had all URLs showing as red for about two weeks. User:Krenair fixed the red URLs, but I think that magic words like ISBN and PMID links need to be fixed separately. With luck, this will be similar and get finished soon. Most fixes take about two weeks to percolate through testing. Whatamidoing (WMF) (talk) 00:18, 13 November 2014 (UTC)

Witty, I can't reproduce this today, and there was an update this morning. Are you still seeing this? Whatamidoing (WMF) (talk) 00:53, 13 November 2014 (UTC)

Yes, I still see the problem Whatamidoing (WMF). To replicate... I went to Sydney Mechanics' School of Arts and in the further reading section at the bottom you'll see a book by Garry Wotherspoon. I opened the 'edit (beta)' system and clicked on that line. It's a "cite-book" template so it opens up the dialogue box. I then replaced the current (Bluelinked) ISBN numbers with another series of numbers for a book that I KNOW exists (any book, doesn't matter). I then close the dialogue box and -presto- the link is now red. I didn't save the edit because that's not where the bug lies (and it would introduce an error into the article) but you can replicate it this way, I hope. Best, Witty lama 01:37, 13 November 2014 (UTC)

Thanks for this reply. I figured out my mistake: I can reproduce this here at en.wp in both Safari and Firefox, but not at Beta Labs, which is where I was testing it earlier. So the fix apparently is already on its way. Whatamidoing (WMF) (talk) 06:39, 13 November 2014 (UTC)

Another <nowiki/> in a link

I know you're working on this, but here's another example of an inserted <nowiki/>, which in this case causes the link to go to the wrong place. [27].

What is meant (and what is shown in the VE edit mode) is [[Haran (biblical place)|Haran]]. Instead, we have [[Haran (biblical place)|<nowiki/>]][[Haran]], which means that the visible link does not go to the place page as intended.

On the good side, I found moving a reference's location much easier than I had expected. Thanks! -- Ypnypn (talk) 20:39, 11 November 2014 (UTC)

Thanks for the note, Ypnypn. Yes, the "invisible" (good) link with a nowiki tag has been around for a long time. Sometimes it ends up as a series of links, some visible and some not. User:SSastry (WMF) has been working on it. It's a difficult problem.

I'm glad that you liked the way that refs can be moved. Have you seen the new table editor, which just arrived today? You can delete (or add) an entire column from a wikitext table in just two clicks: select the column and click on 'delete column' (or 'insert' for an extra). They've got all kinds of plans for wikitext tables (like being able to rearrange columns by dragging and dropping them), but I think that this is a good start. Whatamidoing (WMF) (talk) 00:22, 13 November 2014 (UTC)

Whatamidoing (WMF) I have a suspicion this one is a VE issue where Parsoid gets HTML that consists of 2 separate <a> tags. If this is consistently reproducible, it is easier to check / verify. SSastry (WMF) (talk) 19:24, 13 November 2014 (UTC)

Six bugs and issues

Random article: Pad Abort 1 (Orion). The gallery is centered using <center> tags. These can't be edited (or even noticed) using VE, it seems.
When I add a template; I briefly get ugly black lines on top and bottom of the "add template" button.
Add a template. Put cursor after the newly added template. Click "undo change". Everything but the undo and redo button on the left, and the "help" "page options" and "save" buttons on the right, are greyed out, even though the cursor is blinking nicely at the place you inserted the template.
Categories: you can add a different sort for specific categories (although you have to guess that "enter" will do the trick, no "apply" or something similar is available), but you can't remove such a cat-specific sortkey.
On pages with quite a few categories, like Aleksei Vladimirovich Semyonov, when you open the category editor, scroll down, and then click the "i" next to the defaultsort box, you only see a small part of the text. Trying to scroll down to the rest of it closes the information box...
A Wanderer's Notebook has a serious gap in the infobox. No idea whether it is caused by the reference before it, or the infobox syntax. Template:Infobox film is a pretty common infobox though. Fram (talk) 13:46, 13 November 2014 (UTC)

See this recent discussion about the center tag. It should not be used anywhere. Galleries have their own centering option anyway.
I don't see this in Firefox. Does it happen in a private browsing window?
And they stay grayed out if you start typing, but not if you click somewhere else. I'll get you a bug number for that.
Confirmed in Firefox and Safari.
I can't confirm this. I can scroll just fine (two fingers on the trackpad and swipe down) in Firefox and Safari.
This appears to be Firefox-only. Given T72796, I think your surmise about the ref tags is correct, but I'll test it later. Whatamidoing (WMF) (talk) 16:28, 13 November 2014 (UTC)

"Galleries have their own centering option anyway" which can't be accessed, changed, implemented from VE...
No, standard Firefox window. Just tested it again, and it still happens.
OK
OK
Only happens when clicking with the mouse (in the scrollbar), not when using the mouse-scrollwheel or something similar. This is just the same old scrollbar problem probably, as mentioned for VE before.
OK Fram (talk) 07:45, 14 November 2014 (UTC)

Editing boxes have shrunk

I'm not sure if it's because of an update that's going through or what, but the text in the boxes that pop up when you do things like adding references or saving your edits has got really small (like less than size 8). I'm on Chrome on Windows 8 if that helps at all. Red Fiona (talk) 22:26, 12 November 2014 (UTC)

Hi Red Fiona, there was indeed an update today. I'm not seeing this. Is it still a problem for you? Whatamidoing (WMF) (talk) 00:25, 13 November 2014 (UTC)

As of 1.30 this morning, yes. It's not a huge problem but I can imagine it might be off-putting to new users. Red Fiona (talk) 01:29, 13 November 2014 (UTC)

Thanks for the quick reply. Anything that makes it harder to read is going to be a huge problem for some editors. I don't think that anyone who can deal with this is awake at the moment, but I'll let them know tomorrow. In the meantime, if anyone else who sees this wouldn't mind taking a minute to verify this, it would be really helpful to know if this is only on Chrome/Windows 8, or if the problem is broader than that. (It might be everywhere. I usually set a minimum size in web browsers, and that might override this.) Whatamidoing (WMF) (talk) 06:25, 13 November 2014 (UTC)

I've tested this on a clean Chrome/Windows 8 instance and the text size is fine. You could try the following:

Try VE in a private browsing session (press ctrl+shift+n) to make sure it's not a caching issue or a browser plugin
Try VE while logged out (add ?veaction=edit to the end of an article URL) to make sure it's not a user CSS problem.

ESanders (WMF) (talk) 10:29, 13 November 2014 (UTC)

I've followed ESanders (WMF) suggestions. On a different computer (Windows 7, IE) I still have the problem, but only when I'm logged in, if I am logged out it goes back to normal. I tried clearing the cache but it didn't seem to do anything. I'll try the ctrl shift n thing next.Red Fiona (talk) 16:38, 13 November 2014 (UTC) Quick Edit Tried the ctrl shift n thing. It also didn't work. Red Fiona (talk) 16:43, 13 November 2014 (UTC)

Having tried this using Firefox on LinuxMint17, there's still a similar problem but it's not anything like as bad as it is on Windows. If it is a user CSS problem, how do I fix it? Red Fiona (talk) 14:42, 14 November 2014 (UTC)

Your user CSS would be at User:Redfiona99/vector.css, assuming you're using the Vector skin (that's the default; you can check which skin you're using via the "Appearances" tab of your Preferences). Since that page doesn't exist, you don't have any user CSS that might be causing problems (again, assuming you're using Vector as your skin). -- John Broughton (♫♫) 20:04, 14 November 2014 (UTC)

It turns out I was using Monobook. Switching to Vector has solved the problem. Thank you very much. Red Fiona (talk) 20:51, 14 November 2014 (UTC)

Why was bug 51669 closed?

User:Jdforrester (WMF), why did you close bug 51669[28] as "resolved fixed" over the summer?

The bug is "When dragging an item in the visual editor (tested with image and text), the editing window does not scroll up or down when you reach the top or bottom of the window."

It was reopened bvy a more attentive WMFer only 6 hours later. Can you please explain what you believe was fixed, and how you tested this? My first test, opening List of spaceflight-related accidents and incidents and dragging the image down, didn't work. Dragging something (e.g. a reference) "up" beyond the screen boundary doesn't work either, as tested in 2010–11 Vancouver Canucks season. So what did (does?) actually work that made you decide to close this as "rersolved fixed", and which release (over the summer) supposedly had fixed this? Fram (talk) 12:08, 17 November 2014 (UTC)

My first test, in my sandbox and using Firefox, worked exactly as expected. I can drag text or a template from the top of a long sandbox all the way to the bottom. I believe that James F also primarily uses a Mac. Perhaps this is a Windows-only problem? Whatamidoing (WMF) (talk) 01:26, 18 November 2014 (UTC)

Reproduced on Windows 7, Firefox. -- Ypnypn (talk) 01:29, 18 November 2014 (UTC)

If what you say is correct, Whatamidoing, then it is rather terrible that User:Jdforrester (WMF) hasn't really learned anything from the previous two years. "It works for me on my minority system, so I'll close it" is not proper testing. The problem was explicitly listed for nearly all systems (but not for Mac). Testing it on your own system and reporting that that works, fine. Closing a problem that has been listed for Windows (7 and Vista) and Linux because it works on your Mac? Shameful. (I note that he edited at enwiki yesterday evening, so he has surely seen the previous ping. Doesn't feel the need to explain his incorrect actions apparently. "My job is to help make sure the VisualEditor team understands what the community wants and needs, is focussed on the things that matter, and is engaging with and understood by the community." Please do your job properly) Fram (talk) 07:53, 18 November 2014 (UTC)

Internal links damaged

When will VE stop damaging internal links like here ? A correct internal link [[College Party]] replaced by a nonsense [[College Party|<nowiki/>]][[College]] Party. Even if the contributor did something wrong, the internal link with just a nowiki as the displayed text is total nonsense. --NicoV ^{(Talk on frwiki)} 17:25, 21 November 2014 (UTC)

Adding more fields to a reference

Just noticed, probably a known issue: when I edit Aleksei Vladimirovich Semyonov, open the one ref, choose "add more information": for every field you want to add, you have to repeat the whole process: you select the field, the "add more information" box disappears and you scroll to the top of the reference, not to the newly inserted field. If you want to add 5 fields, this is quite tedious. When I do the same for standard templates, the screen at least scrolls immediately to the new field, which is a lot better of course. Fram (talk) 07:45, 14 November 2014 (UTC)

This was reported a while ago (maybe even by you). I agree that it's quite tedious. I want it to leave the "Add more information" list open (ideally with whatever I've just searched for, because having to separately find 'editor last name' and 'editor first name' is particularly irritating). Whatamidoing (WMF) (talk) 18:14, 21 November 2014 (UTC)

Nonsense titles

A VE edit that damaged an article by putting a title formatting around a br tag. --NicoV ^{(Talk on frwiki)} 18:42, 21 November 2014 (UTC)

That looks like a plain old user error to me. If you put your cursor on any line and choose a different section heading, then you will get a section heading, even if a section heading is inappropriate for the content of that line. Whatamidoing (WMF) (talk) 19:51, 21 November 2014 (UTC)

Tables

Happy to see that finally we can add/remove columns on tables using VE. But the new update comes with a small problem. While I am given the option to add/remove columns or rows in an already existing table, I am not given the option to edit the boxes content. Or maybe I can't see how I can do it...? I don't know but when I am clicking on the box I expect to get the "edit" option as well. Haven't checked yet the creation of a table and if it's possible with VE, hopefully I'll check that out soon too. Thank you for all of your work with VE. I am using Firefox 33.1/Windows 8 TeamGale 12:09, 14 November 2014 (UTC)

Hi TeamGale,

VisualEditor's approach is much more convenient for adding and removing columns, isn't it? For editing the contents, try double-clicking in the cell. It's not always obvious whether your click was "select the cell" or "start typing here". Whatamidoing (WMF) (talk) 20:32, 14 November 2014 (UTC)

Thank you so much for the answer. Double clicking works indeed! But it's true that is not really obvious. Maybe an "edit" pop up will be more helpful when you click once on the cell?

And something else, while I can edit the content in simple tables with double clicking, seems like I can't do the same in tables like the one in this page. Double clicking works only on the very first row but not on the cells below. Before the update, I could edit those cells by just clicking on them and work on them as templates since they are templates. But now I can't do it... TeamGale 09:11, 15 November 2014 (UTC)

And I also can't edit any of the cells of the table in the "Episodes" section of The Vampire Diaries (season 6), when in VisualEditor. -- John Broughton (♫♫) 00:22, 19 November 2014 (UTC)

Any update on that? Anyone? TeamGale 22:48, 20 November 2014 (UTC)

I've just given your example to the dev who is doing most of the table work. When I try to edit that table, control-click says that it's an image, which is very weird. The entire Bugzilla: database is being moved to Phabricator: this weekend, so I can't give you a bug number. Whatamidoing (WMF) (talk) 18:11, 21 November 2014 (UTC)

An image? I personally don't get that. Only that when I click on any of the cells, the whole page get selected like I run the mouse over it. Before the last update where now simple tables can be edited, I could edit those kind of tables without any issues. This appeared after the update for the tables. I don't know if it's just a coincidence or the two are related but I believe they are related somehow. I hope it's something that can be fixed soon. Thanks for the answer and please keep us updated about it when there is something new. TeamGale 20:13, 21 November 2014 (UTC)

I'm convinced that they're related. (Of course I might be proven wrong, but...) Realistically, I expect the fix for this problem to take at least two weeks to get here. Whatamidoing (WMF) (talk) 22:31, 21 November 2014 (UTC)

Information missing from User Guide

Hi, the User Guide (http://wiki.riteme.site/wiki/Wikipedia:VisualEditor/User_guide) says in the first paragraph "Because unregistered editors cannot specify preferences, the only way they can use VisualEditor is by specifying the URL parameter". This is phrased as if we somehow are expected to already know what the "URL parameter" is, or as if it is explained somewhere nearby and obvious, neither of which is the case.

I've revised that wording to make clear exactly what needs to be done. -- John Broughton (♫♫) 21:10, 24 November 2014 (UTC)

Mac Safari page scrolling with keystrokes

Hello - I know that bug-reporting is closed until monday, but I thought I'd mention this here in case it's been covered already. VE scrolls the page (by one increment) with every keystroke in Safari 7.1 on Mac Mavericks 10.9.5. Chrome (also using Webkit) has no such problem. Thanks, and cheers. THEPROMENADER ✎ ✓ 09:13, 23 November 2014 (UTC) PS: This doesn't happen when the page is scrolled all the way to the top ('floating bar' not showing). THEPROMENADER ✎ ✓ 09:15, 23 November 2014 (UTC)

Thanks for this note, ThePromenader. This very annoying problem has already been reported, and Ed is supposed to be fixing it (ideally before I have to do something really drastic, like installing Chrome). He will be very happy to have your "PS" detail, because that may be the key for turning a "sometimes it happens to me but not always" into a reproducible problem. Whatamidoing (WMF) (talk) 20:58, 25 November 2014 (UTC)

You're welcome, anything I can do. It -is- annoying, isn't it? I've had to work between Safari and Chrome. It only began a few days ago, if that adds anything. THEPROMENADER ✎ ✓ 21:02, 25 November 2014 (UTC)

Hidden comments

I know this issue has been raised before, but I thought it's worth reiterating that VE should have a way to display hidden comments. Edits liks this one would be avoided and would not need to be reverted. Parsecboy (talk) 13:33, 25 November 2014 (UTC)

VE does show the user that there's a hidden comment there -- if you edit the article in VE you'll see a button with an exclamation mark on it at that point in the text. Is this enough, or do you think it should also show at least the first few characters of text? Mike Christie (talk - contribs - library) 13:51, 25 November 2014 (UTC)

If you either hover over the (!) icon, or click on it, then you see the whole text. Whatamidoing (WMF) (talk) 21:02, 25 November 2014 (UTC)

Newly made links are red until page is saved

Tracked in Phabricator
Task T75741

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	I was trying to make an infobox.
Steps to Reproduce:	1. First, while logged in, make a subpage of your userpage on the browser and browser version in the "Web browser" row. 2. Then, put the template "Infobox road" into the page. 3. Finally, add parameters that make links. The links will be red instead of blue.
Results:	What happened?
Expectations:	I expected the links to be blue.
Page where the issue occurs	https://wiki.riteme.site/w/index.php?title=User:Philroc/South_Dakota_Highway_37A&veaction=edit
Web browser	Google Chrome version 34.0.1847.116 m
Operating system	Windows 7
Skin	Vector
Notes:	File:Philroc-VEBug.png
Workaround or suggested solution

Phil roc^{My contribs} 14:23, 24 November 2014 (UTC)

Philroc, is this only in templates, or also in plain paragraphs? User:Krenair will need to know. Whatamidoing (WMF) (talk) 21:00, 25 November 2014 (UTC)

@Whatamidoing (WMF): It is only in templates, but I haven't tried out other templates yet, just Infobox road.

I found a similar issue in {{Main}}. - Ypnypn (talk) 23:09, 26 November 2014 (UTC)

@Ypnypn: Try out a few other templates, if they all have the problem, tell me. Phil roc^{My contribs} 21:16, 27 November 2014 (UTC)

Categories moved into ref tags

Tracked in Phabricator
Task T74048

When will this one be fixed ? I'm tired of fixing articles damaged by VE... I tried to add information on bug 72048 with 2 new instances, including one done by a registered user, but it's not possible due to the migration to phabricator. Here's the text I tried to post:

Still damaging articles:

https://fr.wikipedia.org/w/index.php?title=Danah_boyd&diff=prev&oldid=109280098 : this one is by a registered user, maybe you can ask him what he did ? I let a message on this user's talk page https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:SashaWolf#Probl.C3.A8mes_avec_l.27.C3.A9diteur_visuel

Answer: IE, W8. He said there was some editing problems, and he didn't manage to put some text (no more precisions). --NicoV ^{(Talk on frwiki)} 09:49, 21 November 2014 (UTC)

https://fr.wikipedia.org/w/index.php?title=H%C3%B4tel_George-V&diff=prev&oldid=109295400

--NicoV ^{(Talk on frwiki)} 09:05, 21 November 2014 (UTC)

Everything in Bugzilla is being moved to Phabricator this weekend. If all goes well, it will be up and running no later than Tuesday. Phabricator has one feature that I think everyone will appreciate: your regular Wikipedia username and password will work there (with OAuth), so no separate account and no nasty habit of displaying your e-mail address to everyone in the world.

Unfortunately, I don't know when this will be fixed. It's a very odd problem. I'll pass along the note that it might be associated with Internet Explorer. Whatamidoing (WMF) (talk) 19:46, 21 November 2014 (UTC)

So, what happens to my block at Bugzilla? Somehow transferred to Phabricator, or nullified? I suppose the updates I get via mail on bugs I posted before my block continue to work? Fram (talk) 18:13, 22 November 2014 (UTC)

I don't know the details. I'll ask. Whatamidoing (WMF) (talk) 21:04, 25 November 2014 (UTC)

Hi Fram, it appears that there has been an informal general amnesty for non-spammers who were blocked on Bugzilla. Anybody is welcome to participate in Phabricator, so long as they're following mw:Bug management/Phabricator etiquette. I think that people who are used to the English Wikipedia may find that their community standards are a bit on the strict side.

The instructions for staying on the mailing lists is at mw:Phabricator/Help#Receiving_updates_and_notifications. Good luck, Whatamidoing (WMF) (talk) 01:20, 28 November 2014 (UTC)

Thanks. Fram (talk) 07:24, 28 November 2014 (UTC)

Insert media

I have no idea how to insert a picture from Wikimedia when using ve. I clicked on Insert and then Media. I got a page full of previously inserted media in separate boxes but couldn't see any place to add anything. Kdammers (talk) 08:56, 27 November 2014 (UTC)

@Kdammers: When you open the insert media dialog box, VE uses the title of the page you're editing to search Wikimedia Commons, and displays a group of images that you might want to insert. It's quite likely, for an established article, that one or more of those images is already in the article. Perhaps VE should not display images already on the page, or - better yet - should have a checkbox, unchecked by default, that says "Display images already on the page".

More practically: the words(s) that VE is using (the page title) for its search should be highlighted when you open the insert media dialog box. You should be able to change the word(s), and thus change the search. -- John Broughton (♫♫) 19:21, 27 November 2014 (UTC)

Thank you, John. Yes, the practical solution for the current set-up worked quite well. but it really needs to be pointed out to users; it is any-thing but intuitive to me. Kdammers (talk) 09:32, 28 November 2014 (UTC)

Hello there. So, assuming that you're correctly getting the dialog as shown here, the word in the search box (I think the magnifying glass is enough to explain what that field is for?) is actually highlighted — at least the first time you add a pic to the article, I just tried this in Chrome and FF. But if for any reason the displayed images do not satisfy you, you can also copy/paste the name of the pic you want to add, with or without the File: prefix. HTH! I'm also going to check if John's suggestion is already on Phab, otherwise I'm adding it there. --Elitre (WMF) (talk) 11:49, 28 November 2014 (UTC) PS: now at [29].

Editing image caption

This edit of mine had three issues. The only thing I was trying to do was wikilink radome. When I got into the image dialog, I was pleased to find that Ctrl-K worked to bring up the link dialog. However, the dropdown list of link targets was chopped off at the lower boundary of the image dialog -- it's evidently constrained to live inside the parent dialog, which is probably the wrong way to think about it. Secondly, just doing Ctrl-K and picking a target wasn't enough to activate the "Apply changes" button at top right; I had to add and delete a space to the caption to make that pop up. Third, you can see from the diff that the parameter "right" was removed. This seems to have had no effect on the display, so perhaps it's the case that "right" is the default. However, I think VE shouldn't remove it in such cases; it's a minor annoyance that could easily be avoided. If removing "right" actually changes the image's behaviour then it's a more serious bug. The other two are minor annoyances with easy workarounds. Mike Christie (talk - contribs - library) 16:51, 26 November 2014 (UTC)

You're using Firefox, right? I had a similar problem with the "Apply changes" button the other day. Whatamidoing (WMF) (talk) 01:45, 28 November 2014 (UTC)

Hi all :) Here are some replies.

About the dropdown list being chopped, did it look different from this? My guess is that the list of pages can get quite long so you'd need the scrollbar anyway?
Links not triggering the Saving option is [30].
I don't know if dropping the 'right' parameter is a bug or a feature!, so I filed [31].
While testing I also noticed applying wikilinks in the image dialog looked pretty slow, so I added [32] while I was at it. Thanks and have a nice day everyone! --Elitre (WMF) (talk) 11:33, 28 November 2014 (UTC)

Just tested this, and opening a file and changing the caption elso isn't enough to acitivate "apply changes" (tested with Giovanni Berchet, FF, Windows 8.1). Typing some "alternative text" did reult in the "apply changes" being activated. But then the changes I made to the caption aren't shown or saved! Basically, caption editing for images seems to be no longer possible (or at least practical) with VE. Fram (talk) 11:41, 28 November 2014 (UTC)

You are right: I had missed that because I only tested formatting, but I didn't add or remove anything else. This bug should now nail it, I hope. Thanks, --Elitre (WMF) (talk) 12:11, 28 November 2014 (UTC)

I'm using Chrome on Windows 7; sorry, should have said that before. The dropdown does have a scroll bar, and I'm no longer sure what it looked like when I reported the bug, but I suspect I just didn't notice the scroll bar. However, it's sized differently for me -- the scroll panel only shows the first two entries and a part of the third. Even the image Elitre links to is much smaller than the normal scrolling panel for links, though. I tried linking "progress" (outside an image dialog) and "pro" gets me a pulldown of eight or ten options, with no scrollbar. I suppose it's fair to say this isn't a bug, but it seems like odd behaviour -- why do I get a smaller link scroll pane in Chrome than in FireFox when in an image dialog; and why do I get a scrolling pane instead of a longer pane with more options when inside an image dialog?

Re the discussion above: changing caption text doesn't activate "Apply changes" in FireFox; however, it does activate it in Chrome -- I just tested it again on Giovanni Berchet. Mike Christie (talk - contribs - library) 12:51, 28 November 2014 (UTC)

So I can't notice any difference if I keep the browser full-sized, no sidebars, characters size "default" (100%) - like you, I get the full list of the 8-9 options for "pro". When I change the characters size or if I resize the window though, the dialog adjusts accordingly and the scrollbar may appear (and this was the case when I took the screenshot). As for Fram's bug, I did specify it's FF specific in its title :) --Elitre (WMF) (talk) 13:01, 28 November 2014 (UTC)

So you did. Re the scrollbar: I had the browser window maximized throughout my testing. Not sure what your conclusion is -- do you think this is incorrect behaviour? Shouldn't I see the same list of 8-9 options when in the image dialog that I do when not in the image dialog, if my browser window is the same size? Mike Christie (talk - contribs - library) 13:15, 28 November 2014 (UTC)

I think it isn't a bug but a design choice: I wouldn't like the matching pages list to be so long it goes beyond the lower border of the image dialog. But since clarity is better than an educated guess, I asked here (if my wording is not clear enough, please feel free to edit the task or to add details!). Best, --Elitre (WMF) (talk) 15:17, 28 November 2014 (UTC)

Clear template

Not sure if this is really a bug, but the behaviour was initially surprising to me so I thought I'd mention it here. See this edit, which included a {{clear}} template to move the footnotes below the magazine's issue grid. I inserted the template by placing the cursor just to the left of the "F" of "Footnotes", and choosing Insert->Template, typing "clear", and inserting the resulting template. That placed the template like so: =={{clear}}Footnotes==, which unsurprisingly looked odd (it left the header line on two lines). I can see why VE did this -- my cursor position is ambiguous because the "==" characters aren't visible on screen.

I can't think of any easy way out of this, but I wonder if templatedata could be useful. Suppose templatedata included some semantic information that VE understood. Then VE could make some decisions about interpreting those templates when they are inserted. For example, in this case, a trivial example would be "use-inside-headers=no", and VE would then know to slide the template to the left of the "==".

I was also thinking about the fact that VE can't use language-specific templates, since it can't rely on their existence. If VE allowed a user-defined toolbar of templates, much as Word and Excel and similar programs allow toolbar customization, these could be combined with templatedata to provide the ability to organize the toolbar into categories. Then you could have a toolbar showing, for example, an apostrophe as the label for a button; clicking it would insert {{'}}. Templatedata could be used to allow the user to organize the search for templates to add to the VE toolbar, and to give titles to the sections of the toolbar, and tooltips. I'm aware this would be a far-future enhancement, but does this seem a possible way around VE's inability to use local templates? Mike Christie (talk - contribs - library) 12:10, 4 December 2014 (UTC)

Adding a note to say that placing the cursor in the same position and inserting a reference list, as I just did in another edit, works correctly; it places the references list prior to the "==" sign, so evidently VE has some heuristics for disambiguating the cursor position in this case. Mike Christie (talk - contribs - library) 13:23, 4 December 2014 (UTC)

Adding template - visual editor preview doesn't match saved

See this edit - where I replace a raw link with the "main" template. Before saving, the Visual editor shows the link as a redlink and adds an extra line of whitespace above and below the new template. However, when I actually save the edit the link goes blue and the whitespace disappears. So, the saved result is exactly what I wanted to happen, but the visual editor 'preview' made it look like there were going to be two mistakes. Witty lama 13:23, 3 December 2014 (UTC)

Thanks, added to [33] for the moment. Best, --Elitre (WMF) (talk) 15:50, 4 December 2014 (UTC)

span data-ve-clipboard-key

In the last few days, I've stumbled upon a few articles with span tags inserted without any good reason, and those span tags contain attributes clearly dedicated to VE that have nothing to do in an article (Simon Frenay). Please fix. --NicoV ^{(Talk on frwiki)} 18:13, 5 December 2014 (UTC)

It's patch-for-review. Thanks, --Elitre (WMF) (talk) 21:09, 5 December 2014 (UTC)

Suggestion re insert menu inside references dialog

The insert menu has been changed recently; it now has a "More" entry, which reveals extra options. This might make sense in the main editing dialog, but inside the reference dialog I think it's a mistake -- the menu would have had six entries without the "More"; now it has four, and seven when expanded (since there's a "Fewer") option added to the end. Six doesn't seem too many for this dialog. If the change stays, I'd suggest moving the special characters above the "More", since en dashes are often needed in references. Of the options on the menu, I'd think "table" and "media" are the least likely to be used in the references dialog, so perhaps those could be moved down in that situation. Mike Christie (talk - contribs - library) 02:25, 2 December 2014 (UTC)

mw:Wikipedia:VisualEditor/Feedback/Toolbar looks like a good place for this kind of feedback (or other relevant pages at mw:VisualEditor/Design). I'd suggest you copy it over there and ping James :) --Elitre (WMF) (talk) 15:39, 4 December 2014 (UTC)

"Table" isn't an option (this week, anyway). I have Media, Template, Comment, Gallery, Formula, and Special Character in my list. Of those, I expect that only Template and Special Character will see much use. Whatamidoing (WMF) (talk) 20:24, 8 December 2014 (UTC)

Is there a way to add or change a template description?

Possible Bug

What's the current status on the look and feel of image slugs?

Clicking on a template making a link goes to that link

Ctrl-RightArrow should move to start of word, not end of word

Color coding the wikitext editor

The "beta" word

No easy way to find images by name in article.

Link editor: incorrect "new page"

Longer drop-downs don't work

Various problems

Edit summary bug fixed in edittop

DEFAULTSORT and categories moved + other problems

Categories split in two places, with some in double

Status of copying tables

nowiki and damaged internal links

Quotes added to otherwise unmodified references

Take highlight off citation after insertion

Any chance of getting my edits back?

"Something went wrong" but edit was saved

Highlight disambiguation links and show all options on the disambiguation page for fixing them.

Autoupdate citation list

Table formatting modified by VE

Cut and paste of a table gives nowiki

References format modified by VE

VE finally working in Internet explorer!

nowiki around whitespace just before a colon

Section editing and edit conflicts

Group refs question

Three tries, three fails

Stub (and other) tags

Awesome

Use positional parameters for templates with no parameter name chosen?

Up and down arrow keys

Unexpected behaviour editing a link

References

Have VE list all cite templates?

Problems and minor issues

More problems and issues

Missing bugzillas

Various VE errors in the recent changes

Pawns? still

TemplateData autovalue and VE

Image didn't show up in search

Can't differentiate between SVG and PNG files.

Bug in Save page dialog

Italics and nowiki

Visual editor adds unwanted quotation marks

Autofill "date accessed" field when adding citations

Alt text not saved

Categories moved into ref tags

Editing notes results in an odd preview.

Manage TemplateData

Adding infoboxes is painful

Possible Bug

No way to add a title to an external link with no title

External links in refs become redlinks in VE?

Wrong reference numbers in article text

User guide

Old list

Not obvious how to cancel editing

Copy/paste in VE followed by adjacent delete

Adding to lists

SUBSTed defaults in templates

Template:Citation needed span

Unnecessary succession of nowiki

Edit conflicts destroying work in VE

Error message when using VE to edit sandbox

Odd Error Message Editing Patrícia Ferreira

Slow in chrome

ISBN link in cite-book shows as a Redlink

Another <nowiki/> in a link

Six bugs and issues

Editing boxes have shrunk

Why was bug 51669 closed?

Internal links damaged

Adding more fields to a reference

Nonsense titles

Tables

Information missing from User Guide