Jump to content

Wikipedia:VisualEditor/Feedback/Archive 2014 3

Add links
From Wikipedia, the free encyclopedia


Testing report from Wbm1058

This report was originally posted at Wikipedia talk:VisualEditor/2014 RFC.

I'm one of the minority of editors who has opted in, perhaps in a show of "moral support", so sees the edit (beta) tab, but virtually never has used it for the past several months. I realize I may not be part of the target market for VE, but nonetheless, I'll try using it for all of my edits, and report on each, until I tire of that. Wbm1058 (talk) 15:42, 9 June 2014 (UTC)

Removing a template

  • Sorry, I gave up on this attempt. Could not figure out how to remove this template and comment with VE, after some good-faith fiddling with it. Wbm1058 (talk) 15:42, 9 June 2014 (UTC)
    • You may have been looking for a more difficult solution than necessary. You just select it and press the backspace/delete key. Whatamidoing (WMF) (talk) 19:25, 10 June 2014 (UTC)
      Really? The program has trained me too well. I know that adding a template directly is verboten... I need to use the "template tool" thing to do that. So I assume that I need to use the same tool to remove templates as well. Why should it support just backspacing over "wikitext". But OK, I'll try that next time. Wbm1058 (talk) 03:46, 11 June 2014 (UTC)
      @Wbm1058: In VisualEditor, everything can be edited "directly" (except for a very few items like <hiero>), including random <div>s and so on; however, you're confusing a template invocation (which looks like {{foo}} in wikitext and <… mwt="…"> in HTML) with the template output (which is what you care about). Wikitext is not "verboten", it's just meaningless chaff. It's a serious context-switch, I agree, and takes a little getting used to. Jdforrester (WMF) (talk) 21:32, 20 June 2014 (UTC)
      @Jdforrester (WMF): "Wikitext is not "verboten", it's just meaningless chaff." Untrue. Wikitext is "verboten", completely, apart from the cases where VE can't handle it, and there it is mandatory (which is of course a quite ridiculous way of doing things). But otherwise, totally and utterly verboten by Erik Moller and you, even though technically there was no reason to do so. And to enforce that ban, you (WMF devs) turn every attempt at Wikitext into "meaningless chaff". It's not a context-switch that takes getting used to, it's one of the main reason many people don't care about VE one bit and have no interest at all in getting used to it. Fram (talk) 08:19, 22 June 2014 (UTC)
      @Fram: This is not true, but given that we've had this discussion several times I'm not sure it's worth your time trying to explain again otherwise. At the very least, please stop spreading this dis-information to others as if it were correct. Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)
      @Jdforrester (WMF):, I don't see what is "not true" in Fram statement. I may be mistaken, but I have the same understanding as him about wikitext being forbidden in VE except where it's required because VE can't handle it (yet?). When I read comments from you and Erik in bugzilla 49686, I strongly feel that wikitext syntax is forbidden in VE by choice. NicoV (Talk on frwiki) 17:00, 23 June 2014 (UTC)
      Agreed with NicoV above. If it is not "verboten", then please indicate how it is allowed (except in those cases where it is mandatory, as described below). I suppose you mean that it isn't worth your time trying to explain it again, it certainly is worth my time and it is a rather strange cop-out on your part to avoid an explanation out of consideration for my time. Seeing that other people with a long involvement with VE don't seem to understand (or believe) it either, I feel it would be best that you actually showed us why my statement is "dis-information" while yours is the Truth, even though it very strongly looks the other way around. If you can't or won't, then it would be best if you stopped repeating the same nonsense over and over again, considering that with your position you should be an authoritative and trustworthy voice about VE. Fram (talk) 06:34, 24 June 2014 (UTC)
      • Look at the Self-brand article history to see my attempts. When I click on the {{user sandbox}} template, it is highlighted in blue and I see a "pop-down balloon" with a puzzle-piece icon that says "User sandbox". At this point, if I hit my backspace or delete key, nothing happens. Is something supposed to happen? Oh, I see. If I click just past the template instead on directly on it, then I see my cursor is positioned there (flashing vertical bar). A single backspace highlights the template in blue and brings up the balloon as before, and then a second backspace removes the template. My, I have found the magic keystroke combination that tells the "template troll" to let me proceed with my VE adventure game ;o) Then I click "save changes"... "review your changes" (I would prefer "review your changes" to be a one-click rather than a two-click request) and see that the comment <!-- EDIT BELOW THIS LINE --> is still there. Is there a way to remove this comment with VE? If not, then I'm not really saving any time by using VE for this edit. Now I note that in this version the [edit source | edit beta] links are missing from that section, so I edit the entire article with a conventional edit to remove the unwanted comment. While I basically agree with Fram's comment above, I sense that tone has been tried before, without advancing the conversation. I'll try a new approach, and open a new section on "context-switch" below. Wbm1058 (talk) 19:50, 22 June 2014 (UTC)
        @Wbm1058: You're right, we temporarily broke backspace working when you select a template – sorry about that. It's fixed in the version of the software that will be released here on Thursday. Viewing, adding, editing and deleting comments isn't yet supported, which I agree is a pain and we're working on correcting right now. I don't understand your comment about section edit links – historical views of pages' revisions don't get section links, only the current version, so isn't this as expected? Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)
        Right, my permalink was only good for demonstrating the issue when it was the current version. Make the following a section title on the current version of a page, and you should see what I mean. I think the comment at the beginning of the line must be messing it up.
        <!-- EDIT BELOW THIS LINE -->==The Use of YouTube and Self-Branding to Promote a Brand==
        —Wbm1058 (talk) 17:41, 23 June 2014 (UTC)
  • The built-in disambiguator is nifty, and I figured out that clicking on the trash can removed the link. This is serviceable, but I still believe that the religious refusal to support [[ ]] in VE is seriously holding back its acceptance. Wbm1058 (talk) 15:56, 9 June 2014 (UTC)
    @Wbm1058: By "disambiguator" you mean the link editor? Yeah, I agree that the rubbish bin isn't very obvious – we're going to replace the icon in favour of the word "remove" in the coming few weeks. I wouldn't describe our view on what keyboard shortcuts make sense to users as "religious", and I would disagree that the absence of a shortcut is "seriously holding back [VisualEditor's] acceptance". Happy to discuss further, of course. Jdforrester (WMF) (talk) 21:32, 20 June 2014 (UTC)
    Not religious, but pretty fundamentalist nevertheless. Have you had many editors thanking you for the refusal to accept "[[" and "]]" as shortcuts in VE? Have you many examples of people using "[[" in the mainspace who actually want to display two square brackets? On the other hand, you've had an RfC clearly asking to allow such wikitext, you've had numerous editors asking for it, you've had bugzillas for it... You may be happy to discuss further, but Erik Moeller has made it pretty clear that the decision is final and that such wikitext is and will remain "verboten" for ever and ever, amen. But, I'll bite, if it isn't this that is seriouslu holding back VE's acceptance, then what? On wiki's where it it and has been the default editing environment for 6 months or a year now, it still is only used for about 10% of the edits, and this doesn't seem to be increasing. So something is holding back the acceptance. I can imagine a number of reasons, you have summarily dismissed one of them, so let's hear what then is, according to you, the reason or reasons that are responsible. Fram (talk) 14:34, 22 June 2014 (UTC)
    Interjecting just to say that I am one editor, at least, who feels the decision not to allow wikitext in VE is correct. Mike Christie (talk - contribs - library) 14:48, 22 June 2014 (UTC)
    Any particular reason? Benefits of that decision are...? Fram (talk) 15:02, 22 June 2014 (UTC)
    To be honest, I'd rather not get into that discussion. You seem to strongly disapprove of VE and the way the rollout's been managed, and frequently post comments to that effect. I posted the note above (and have made similar posts once or twice before) really just to indicate to readers of this page that there is some variation in how VE is viewed by experienced editors. I don't expect either you or I would change our opinions if we were to debate it, so I'd rather not; I'm not even arguing that you're doing anything wrong in your posts. I just don't agree, and would like the discussion on this page to reflect the range of opinions about VE. Mike Christie (talk - contribs - library) 15:14, 22 June 2014 (UTC)
    You have every right to have a different opinion of course, but without anyone presenting me with any real benefits of not having wikitext allowed in VE (except in those cases where it is mandatory), I'm not likely to change my position or approach, and I'll continue to believe that those editors opposing wikitext in VE do this from a purely philosophical position, ignoring the practical implications of that approach (and the wishes of the majority of editors who have discussed this). This only becomes a problem when those with that position are also the ones making the ultimate decision (so not you, but the WMF "leaders"). Not surprisingly, they don't seem to feel the need to explain this coherently or even truthfully, as evidenced by Jdforrester's comments here. Fram (talk) 07:07, 23 June 2014 (UTC)
    Fram, what are the cases where Wikitext is mandatory? Wbm1058 (talk) 12:57, 23 June 2014 (UTC)
    From "random articles", first hit, Stanley Marcus: things where you have to use wikitext in VE: open the infobox, what do you get in the first two fields? {{Birth date|1905|4|20}}, [[Dallas, Texas]]. Further down, another few like this, and the field "spouse": Mary "Billie" Cantrell, 1932–1978 (her death); <br>Linda Cumber Robinson, 1979–2002 (his death)<ref name="lifebooks1">David R. Farmer. [http://books.google.com/books?id=ZOfr0t85tOgC&pg=PA141&lpg=PA141&dq=stanley+marcus+%22linda+robinson%22+married&source=web&ots=FLOxh1atju&sig=ooKzfhx9QRk0wDY07bUxflptnCc ''Stanley Marcus: A Life with Books''], [[Texas Christian University|TCU Press]], 1995, p. 141. ISBN 0-87565-147-X. Retrieved 2008-05-23.</ref>. In the cquote box further down, you get Stanley Marcus<ref name="halkias">Maria Halkias. "Retail legend Stanley Marcus reflects on industry at war", ''The Dallas Morning News'', December 25, 2001</ref>. Similar things happen on most slightly developed articles, e.g. in Elizabeth (soundtrack) on all templates (e.g. the succession box). By the way, what's up with the templates, some get the icon (plus desc) at the top, some at the bottom, making it harder to find things... Not an improvement. This one looks terrible in VE, and has the same issues. Not only templates have this, also e.g. galleries (see Macaw for an example). Fram (talk) 15:05, 23 June 2014 (UTC)
    • Oh, I see. Yes, "link editor". I'm not sure what made me think it included disambiguation capabilities like Dab solver, but it should. My gosh, is that still only on Toolserver? Losing that tool would be a tragedy. Wbm1058 (talk) 19:50, 22 June 2014 (UTC)
      @Wbm1058: When you say you want that tool inside VisualEditor, what do you mean? That tool scans the page for links to pages which are tagged as disambiguations and prompts you to fix each one – would you want that exactly, or something which takes the opportunity when you're editing a link that points to a disambiguation page? Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)
      I think I explained better what I mean in this section, and you understand now. Wbm1058 (talk) 18:35, 23 June 2014 (UTC)

Making redirects

  • After some fiddling with it, I figured out that the 105th Belmont Stakes redirect can be created using the options dropdown. But the refusal to let me do it any other way, leaves me feeling the attitude, "This is France, you should not speak English here" (even though we understand the language). What's the problem with supporting multiple methods of accomplishing a task? Wbm1058 (talk) 16:22, 9 June 2014 (UTC)
    @Wbm1058: There's no "refusal" to have multiple methods to set redirects here, and I think you're reading into the absence of a second method more than the truth, which is that we've not had any suggestions about alternative methods. How would you like these to work? It's true that creating a page as a redirect is quite a common action, but quite a destructive action, so there's a need to set a balance of accessibility/availability/ease of access to avoid some disruption for you and others from newbies. Jdforrester (WMF) (talk) 21:32, 20 June 2014 (UTC)
    Well the alternate method I want to use is #REDIRECT [[1974 Belmont Stakes]]. I tried that, and saw a message that said Wikitext markup detected. Hence my comment above: "we know what you mean, but doing it that way is verboten". Wbm1058 (talk) 19:50, 22 June 2014 (UTC)
    @Wbm1058: Again, not "verboten" so much as "doesn't work". The warning is a (temporary) reminder system to stop people writing wikitext in when it doesn't work, because others would then need to come along and clean it up. Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)
    This has devolved into an argument over semantics, which isn't helpful. The reason it "doesn't work" is because VE always makes the usually erroneous assumption that the editor intended to wrap the Wikitext in "nowikis". This is an important issue, which I've broken out to a new section. See #context-switch. Wbm1058 (talk) 18:01, 23 June 2014 (UTC)
    It doesn't work because you and Erik Moeller have explicitly and without good reason made it "verboten". I don't get how you can deny this simple truth. Yes, of course, if you wrap all wikicode in "nowiki" by default, then it won't work, but that's not becvause VE can't handle it, but because you have disallowed it. You've made a poor tool worse from the start and against the wishes of a mjoarity of actual editors, and not only refuse to rethink that strategy but even refuse to be honest about it (even though it was admitted quite plainly originally; it seems as if you now regret that openness). If you are not willing or able to tell us the truth, then simply shut up, but don't annoy us any longer with evasiveness, blustering, half-truths, and unfounded counter-accusations. They don't help to rebuild the trust between enwiki (and other wikis) vs. WMF at all. Fram (talk) 06:41, 24 June 2014 (UTC)
    Fram is being harsh, but, lacking a better explanation, I'm being led to the conclusion that a management decision was made to invoke a form of "shock therapy", the idea being that it is best to, in the short term, cause a little bit of intentional disruption to the current Wikitext way of editing, because this furthers the long-term interest of a full conversion to the superior "visual" way of editing, in the shortest time possible, i.e., don't let editors use crutches which might delay the transition. Today "shock therapy" carries with it a negative connotation, as indeed the economic disruption of Chile, where this was tried, was severe, and, in hindsight, the economic theories on which the rationale for this "therapy" was based, are looking more and more flawed. Can you confirm or deny whether this was a factor behind the "nowiki" decision? Wbm1058 (talk) 10:49, 24 June 2014 (UTC)
    @Wbm1058: VisualEditor does not "do" wikitext in the same way that a diesel car does not "do" petrol. They're different technologies. Trying to make VisualEditor "do" wikitext would mean (to slightly abuse the metaphor) adding a second power system to the car, slowing everything down hugely and adding great complexity when it would only help a few people who have difficulty using the controls. There is nothing inside VisualEditor that understands wikitext. There are a few areas where we've not yet built a tool for doing proper rich editing of some content, so instead we show the wikitext for direct editing with Parsoid/MediaWiki; this makes the system slow and so we're working to remove them. In a few months' time there will be fewer instances of users seeing wikitext inside VisualEditor as we build the rich template tool. Jdforrester (WMF) (talk) 16:25, 24 June 2014 (UTC)
    @Jdforrester (WMF): OK. FYI, I worked as a professional programmer for 18 years, so don't be afraid to give me more technical answers. Vague comparisons to automobile fuel systems aren't helpful. And I've come to the conclusion that discussion in terms of supporting "wikitext" may not be helpful either. Again, let's continue this discussion below, in the #context-switch section, where I will add some more specific ideas. Wbm1058 (talk) 21:40, 24 June 2014 (UTC)
    I've seen too many instances where your above explanation doesn't match what actually happened in VE (VE producing wikitext, VE interpreting wikitext), so I don't buy your explanation (never mind the farfetched analogy: a diesel car doesn't convert petrol to diesel before it starts burning it, does it?) You already have and use the wikitext, you interpret it immediately when showing and editing galleries or templates, but you can't do it for the text area? No, you are not willing to do it, that's all there is to it. By the way, what happened to the gallery inserter? Seems to have gone AWOL... Fram (talk) 06:51, 25 June 2014 (UTC)
    The gallery tool was removed from the toolbar about a month ago because it was confusing people. It will come back when it's been improved significantly. In the meantime, if you really need to add a gallery, it's possible to copy and paste one out of another page, and then edit it. (You can still edit existing ones on a page.) Whatamidoing (WMF) (talk) 17:03, 25 June 2014 (UTC)

Requiring template parameters

  • So why isn't VE smart enough to know that this edit should never be allowed? Very annoying that it refuses valid edit attempts, yet allows invalid attempts. I thought I was on the way to deleting the template by clicking on the trash can, but the "save page" button was greyed out and I couldn't figure out what the magic trick was that would un-grey it so I could click on it. Sorry, I will need to fix this one with a conventional edit. Wbm1058 (talk) 16:29, 9 June 2014 (UTC)
    • The devs haven't wanted to make VisualEditor enforce "required" template parameters via TemplateData, because that could cause more problems than it would solve. Imagine if someone defined a template parameter as "required", like a date in a citation template, and you didn't know what to put in the field—or even if the missing information was a problem leftover from some previous edit that you don't know anything about—and you weren't allowed to save the page until you fixed it. Whatamidoing (WMF) (talk) 19:25, 10 June 2014 (UTC)
      I suppose it could just have a popup balloon that said "You need to enter a date here", or in my example, "You need to enter the title of the target article here" Wbm1058 (talk) 03:46, 11 June 2014 (UTC)
      @Wbm1058: Yeah, this is a matter of some debate about exactly how we want to highlight that "required" fields aren't fulfilled. We already have the balloons to describe the fields, but they don't pop up unless you click on them (the little 'i' icon) – right now the label for that field is "Name of page that redirects here" (see Template:Redirect#TemplateData if you want to change it). Do you think we should make these descriptions more visible? Jdforrester (WMF) (talk) 21:32, 20 June 2014 (UTC)
      Oh, I see: the little 'i' icon says: "Name of page that redirects here" ... "Field is required." It probably should be more visible. It definitely should be in my face with an error message if I leave it blank, as VE knows that the "Field is required." Wbm1058 (talk) 03:46, 23 June 2014 (UTC)
      @Wbm1058: Thanks for the feedback – I'll look at us changing it to be more "in your face", as you put it. Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)

Redirect creating part II

Automatic edit summaries

  • I figured out how to change categories with minimal effort (although WP:HOTCAT is more efficient for this). Why didn't my edit summary automatically show the category change, as Hotcat does? Wbm1058 (talk) 16:46, 9 June 2014 (UTC)
    @Wbm1058: VisualEditor doesn't currently do auto-descriptions of edits (so that people can describe why they made the edits they did rather than wasting time writing in what), but it's a long way off. Jdforrester (WMF) (talk) 21:32, 20 June 2014 (UTC)
    Writing in what is not a waste of time—it lets editors see the "whats" simply by looking at the edit history, saving the need to look at diffs. Often the "why" is self-explanatory and not needed. By making me manually type in edit summaries each and every time, even for very common edits, VE is taking more of my time. I very frequently choose a common edit summary from my browser history, saving the need to retype it. VE should remember commonly used edit summaries. Wbm1058 (talk) 03:46, 23 June 2014 (UTC)
    @Wbm1058: Interesting. Do you think those should be "commonly used by other editors" or just "commonly used by me", or both? Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)
    Commonly used by me. I've kind of staked out my territory on WP, by taking on things that I feel are important, but that few or no others do. One is patrolling Category:Missing redirects (example). I use the edit summary "disambiguation not needed, I created the redirect" so often that all I need to do is type "dis" and then the full text of that summary pops up and I just click on it to select it. The more often I use a particular edit summary, the higher up it floats on the list of suggested summaries to choose from. I believe that this functionality is built into the Google Chrome browser; you will need to somehow duplicate this funcitonality in VE to maintain the efficiency of patrol-type editing. Wbm1058 (talk) 19:11, 23 June 2014 (UTC)
I see this issue is also discussed here. Wbm1058 (talk) 10:56, 24 June 2014 (UTC)

Wikitext in edit summaries

  • Somewhat amusing that in this diff, VE lets me put a [[wikilink]] in my edit summary, even though it refuses to do that in the edit itself! Again, the disambiguator is the best new feature I've seen since last I looked at VE. Wbm1058 (talk) 17:03, 9 June 2014 (UTC)
    @Wbm1058: Yes, wikitext-only summaries are likely going to stay for at least a reasonable length of time (it's not a priority), but I don't see this as a contradiction. BTW, the link editor has been in VisualEditor for over two years – is it a particular part of its more recent functionality that was particularly helpful? If so, is there anything you'd like to see added – for example, I've considered having redirects tell you where they redirect to so you know if it's right. Jdforrester (WMF) (talk) 21:32, 20 June 2014 (UTC)
    In this edit, I saw the link editor, which had several "matching pages" which are actually "begins with" matches, and a single "disambiguation page". Generally we don't link directly to dabs. What it should show is a list of all the links that are on that disambiguation page. So sorry, what I thought was "the best new feature I've seen since last I looked at VE" isn't actually there yet. My mistake. Wbm1058 (talk) 03:46, 23 June 2014 (UTC)
    Jdforrester: Having redirects say their targets would be very helpful:Jay8g [V•T•E] 20:29, 24 June 2014 (UTC)
    @Wbm1058: Understood, we'll work on this. Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)
    I don't know how well this is going to work. Here at the English Wikipedia (but not at other wikis), there should (but it's not always true) be only links to the main pages that the person might seek, with important caveats, including the existence of ==See also== sections, {{sister}} links, and sometimes images. If you just say "all links on Example (dab)", then you're going to be throwing unwanted links at people. Also, when I know that the page I want starts with "Example", then you're going to be burying the link that I do want with a laundry list of links that I know I don't want. Whatamidoing (WMF) (talk) 18:39, 24 June 2014 (UTC)
    Look at the example given in the documentation. In this case Paul Jones is indeed a disambiguation, as nobody with that name has been judged to be the primary topic. VE is working fine for parenthetically disambiguated titles, as these are "begins with" matches, but it's not offering up the naturally disambiguated Paul C. Jones, Paul R. Jones or Paul "Wine" Jones. If the Paul Jones dab is throwing unwanted links, then the answer is to remove those links from the dab page. Trust the content creators to get the contents of disambiguation pages right. Wbm1058 (talk) 19:42, 24 June 2014 (UTC)
    One of the rules of our software development is that if your answer is "the input is wrong", you're starting from the wrong place. :-) Asking for the English Wikipedia community (and hundreds of others) to adjust millions of pages to make our software work better because we couldn't think of a proper way to fix the problem doesn't seem like the best solution (not that I have an actionable alternative right now). :-( Jdforrester (WMF) (talk) 01:08, 25 June 2014 (UTC)
    Whatamidoing & Wbm1058: Perhaps a collapsed section or fly-out menu could be a solution for the too many links issue. The bigger issue, it seems, would be getting the relevant links from the pages:Jay8g [V•T•E] 20:29, 24 June 2014 (UTC)

Clear formatting

  • The "clear formatting" dropdown was helpful for making this edit. Wbm1058 (talk) 17:20, 9 June 2014 (UTC)
    @Wbm1058: Good to hear. This function currently removes links as well as bold/italics/underline/styles, but not "structural" formatting things like heading/pre-formatted/list/blockquote/table/… – does this mix seem right to you? Would it surprise you when you used it? There's a suggestion to change it to not remove links because people don't think of those as "styling" Jdforrester (WMF) (talk) 21:32, 20 June 2014 (UTC)
    Well yes, I just wanted to remove the boldface, not the links. Links and boldfacing should be independent functions. "Styling" is an ambiguous term which probably shouldn't be used. Here's another example of mixed functions that confused me. I wanted to add a new "see also" section with a single bulleted item. Somehow the item was interpreted as a higher-level section title, and I needed to fix it with a conventional edit (see the next edit). Wbm1058 (talk) 03:46, 23 June 2014 (UTC)
    @Wbm1058: Do you think it's possible you accidentally hit the key combination to make an h1 (Ctrl+1)? That's the most likely cause, but should have been obvious. If you can show me how to reproduce the problem I can get it fixed. Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)
    @Jdforrester (WMF): I think I figured out the problem. I like to cut & paste as much as possible to save time. So when I was adding that "see also" to FILe Generator and Editor, I literally was on that page when I cut-pasted the actual page title. VE took me too literally; I thought I was just copying plain text (unformatted) and it copied the font size for the page title as well, which was unexpected. I verified this by cut-pasting from the lead sentence, and it copied boldface text rather than plain text. I didn't think that it would override what the toolbar buttons were set to. After copying the boldface, I was able to undo that with the "clear formatting" drop-down on the toolbar. So this edit got that right, but somehow I stumbled into making the entire lead into a section header! I don't know how that happened. Wbm1058 (talk) 20:31, 23 June 2014 (UTC)
    I think the convention of copy/paste overriding the current input styling is standard -- MS Word certainly does it that way, and I'm having a hard time thinking of other programs that might be exceptions. Mike Christie (talk - contribs - library) 22:25, 23 June 2014 (UTC)
    @Wbm1058 and Mike Christie: Yes, when we implemented this we studied what other common rich editors did to make sure we were consistent. Sometimes it makes sense to veer away from 'standard' to help users better, so we could change it here if you think users will be less surprised that way around, but it would take a little convincing. Jdforrester (WMF) (talk) 00:52, 25 June 2014 (UTC)
    If it's going to remove the link formatting, then the link inspector should be in that menu. By placing it at the bottom of the character formatting menu, I think people will assume that it removes everything in that menu, but nothing else.
    Mike, Google docs keeps all formatting: color, bold, size, font, etc. Whatamidoing (WMF) (talk) 18:44, 24 June 2014 (UTC)

Creating redirects from the target

Summary

Thanks for posting all of this. This is really good feedback. It's very interesting to see what you were and weren't able to figure out easily—what's working for you (not just in the technical sense) and what's not. Whatamidoing (WMF) (talk) 19:25, 10 June 2014 (UTC)
@Wbm1058: +1; this was really helpful, and you definitely are the target demographic (VisualEditor is not just for newbies, the goal is to be a better editor for all content edits for all users, though we've got a way to go before we're perfect). Jdforrester (WMF) (talk) 21:32, 20 June 2014 (UTC)

@Jdforrester (WMF): I appreciate that the product manager took the time to restore my report from the archives and reply, thanks! Reply comments above. I'm not done with my comments, but I'll save what I have so far to avoid potential edit conflicts, and finish later. Wbm1058 (talk) 19:50, 22 June 2014 (UTC) Added more replies. Wbm1058 (talk) 03:46, 23 June 2014 (UTC)

@Wbm1058: You're welcome; thank you again. Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)

Edit notices

Most times I open a page in VE it says "1 notice" (edit notice), but doesn't show what the notice is? Is there actually a hidden edit notice somewhere, or is this a bug? Wbm1058 (talk) 16:08, 23 June 2014 (UTC)

@Wbm1058: This is an artefact of you being a rollbacker and the local wiki's system of showing a blank edit notice to people like you in case you want to make one; it keeps popping back up as a phantom edit notice inside VisualEditor, which is irritating. Sorry, I'll get it fixed again. Jdforrester (WMF) (talk) 16:46, 23 June 2014 (UTC)
Do you mean template editor? Rollbackers can't create edit notices, but template editors can. Wbm1058 (talk) 11:03, 24 June 2014 (UTC)
@Wbm1058: Sorry, yes, whichever of the labyrinthine permissions enwiki has created for this. :-) Jdforrester (WMF) (talk) 00:54, 25 June 2014 (UTC)

context-switch

I'd like to discuss what is meant by this term. The articles on Context (computing) and context switch don't really seem applicable to VE, as they are too low-level technical. Is there an article linked from the Context disambiguation that is applicable to VisualEditor? I think that, as this is a human–computer interface, that Context (language use) is probably most applicable. Wbm1058 (talk) 19:50, 22 June 2014 (UTC)

The meaning of "determined" is determined by the context in which it is used. It is generally easy for a human to determine the context, but harder for a computer. I think that strong artificial intelligence systems are likely able to do this.

Consider the two examples:

  • Early programs supporting file editing were called [[text editor]]s. They used a [[command-line interface]]. An example is [[FILe Generator and Editor]]. When [[WYSIWYG]] word processors were introduced, they represented a significant "[[paradigm shift]]". Users took training classes to learn how to use them.
  • On Wikipedia it is easy to create a [[hyperlink]] to another article. Simply surround the title of the article you want to link to with double-brackets, like this: [[WYSIWYG]].

Can you identify from the context which link(s) should be surrounded by <nowiki></nowiki>, and which should not? A smart artificial intelligence program should be able to guess where. Since I doubt that VE is ready to do that, maybe it can, when it detects user-entered wikitext, automatically throw up a drop-down menu with two items on it: Wiki (the default), and No Wiki.

How about that compromise? Wbm1058 (talk) 04:45, 23 June 2014 (UTC)

If I may interject here, I really like this proposal by Wbm1058. There was a switch editor in development that let you switch from WYSIWYG to wikitext. I think both the above proposal of asking if you want to use wikitext or not and integrating a way to switch back and forth between plain text and wikitext should be implemented, though the first option might render the second redundant.--¿3family6 contribs 19:27, 23 June 2014 (UTC)
@3family6: FYI, the (one-way) switch-to-wikitext feature has been a part of VisualEditor since late last year. We plan to provide two-way switching inside the wikitext editor in time. Jdforrester (WMF) (talk) 01:04, 25 June 2014 (UTC)
Yes! One question, Jdforrester: How do you get the switch editor to work? I used to have John Vandenburg's script, but that doesn't seem to work anymore (probably because of this upgrade).--¿3family6 contribs 01:07, 25 June 2014 (UTC)
@3family6: In the page-options menu next to the 'cancel' button, click "Switch to source editing". It's rather hidden; I was thinking of making a menu off the "save page" button with "Cancel", "Review your changes", and "Switch to source editing" there – do you think that would be any more discoverable though? Jdforrester (WMF) (talk) 01:38, 25 June 2014 (UTC)
@Jdforrester: Ah, there it is! Oh, boy, will I be using this guy! Is there a tag in edit summaries that mention that I switched to source editing, so that my VE usage is tracked? I agree that it is rather buried, but on the other hand, I didn't know to look there since I've been using VE since before a lot of these features came out and thus am not used to them.--¿3family6 contribs 01:44, 25 June 2014 (UTC)
@3family6: Yes - "visualeditor-switched". See the RC filtered feed for that tag for example. Jdforrester (WMF) (talk) 02:05, 25 June 2014 (UTC)
Slightly off-topic discussion about a "wikitext" button

I had an interesting idea about this: How about a "wikitext" button that would allow people to add anything as wikitext and edit anything already on the page as wikitext? This would mean that people could use wikitext if they want and could add/edit anything, even if it is not currently allowed in VE:Jay8g [V•T•E] 16:05, 24 June 2014 (UTC)

Jay8g That's where my train of thought was going. I'm imagining an editor where you can patch together some text, then run into a complex template, switch to wikitext to edit that, and then switch back to the visual editor so you can better see what you are doing (and also preview the wikitext changes that you made). I think something like this would also GREATLY help with the template and table editing issue, as if you can switch back and forth between the two forms of editing, it would make the development of template and table support for VE much less of an urgent issue.--¿3family6 contribs 18:28, 24 June 2014 (UTC)
This has been discussed, and last I checked, was planned for "eventually". It's not too difficult to do the "back" part of "back and forth"; the "forth" part is a little harder, but doable. The bigger problem is that it would be very slow, because you have to take the whole page. Instead of "let me fix this one bit", the process is open VisualEditor (wait), make a change, switch the whole page to wikitext (wait), make a change, switch the whole page back to VisualEditor (wait), make a change, switch the whole page, etc. There's discussion in the team about using subdocuments that (I think) would facilitate this, but it's a pretty major change, and it's not going to happen during the next few months. Probably the first visible indication of progress will be a way to edit only alienated text (stuff that VisualEditor can't edit at all right now), or the ability to switch an image from thumb to inline and back without permanently losing the caption. The bottom line is that it may happen, but not soon. Whatamidoing (WMF) (talk) 18:51, 24 June 2014 (UTC)

I should make more of an effort to meet the Product Manager halfway. I think diving down into specifics will be helpful to finding an agreeable solution to what I still see as a significant roadblock to product acceptance. From now on, I'm avoiding the term "wikitext" as I think different interpretations of what exactly "wikitext" means are getting in the way of discussion that moves forward. Let's start with the well-known syntax of the MediaWiki brand. When I type the shortcut [[ in VisualEditor, I want the program to respond the same way as it responds to the shortcut Ctrl+K. But what about the odd chance that the editor might actually want to enter the text "[[", you ask. Now when I type that, I see a slightly long-winded message that says Wikitext markup detected You are using VisualEditor - wikitext does not work here... and then some complicated instructions about switching to source editing. Replace that verbose pop-up with one that says "I really want to enter [[", and a button to click on to make that happen. No messages about "wikitext" in VE, remember "wikitext" does not work or is verboten in VE (depending on your POV). [+[ is not wikitext. It is a shortcut. Wbm1058 (talk) 23:04, 24 June 2014 (UTC)

@Wbm1058: I don't think a pop-up prompt is a good idea – that'd be really disruptive to the editing flow. Looking at Word, which is the most obvious "'smart' command re-contextualising" editor I've found, it inserts a new transaction (so you go from "[" to "[[" to "Ctrl+K"), and you can "undo" to the previous state at any point. However, when we spoke to users they said that they found changes like this very surprising and disconcerting, so I'd be keen to find another, less intrusive way. What about Ctrl+[ instead? Jdforrester (WMF) (talk) 01:04, 25 June 2014 (UTC)
@Jdforrester (WMF): You've got a user base that is very used to the existing legacy syntax. The idea is to ease the transition. I'm fine with eliminating the popup—including the "Wikitext markup detected" popup—if [[ brings up the link editor. Ctrl+[ could be the override for the rare literal [[ entry. Or the editor could switch-to-wikitext for that infrequent and unusual edit. Or ask someone else (how) to do it. I see what you're saying about it being two "transactions" but this would be an undocumented, legacy operation, and as such, would be rare... except that this syntax is so ingrained I don't think it will be that rare. An editor being surprised and disconcerted because they literally wanted to enter "[[" and it didn't do that... would be rare. Wbm1058 (talk) 02:36, 25 June 2014 (UTC)
I've used VE for, I think, several hundred edits now, and I do still occasionally find myself typing "[[" without intending to enter wikitext; it's just a reflex. If that brought up the same interface that Ctrl-K brings up, that would make sense to me -- as Wbm1058 says, it would just be another short cut. Jdforrester, sorry, I don't follow your discussion of the two transactions and the undo -- can you clarify the issue a little more? Mike Christie (talk - contribs - library) 02:51, 25 June 2014 (UTC)
By "transaction", I think he means one keyboard entry—whether it is a single key like [ or a key combination like Ctrl+K. The latter is more "elegant" in that it is a single "transaction" which can be undone with a single click of undo. By my proposal, a single [ is the actual character, a second consecutive [ implicitly undoes that and converts the two-transaction combination into an implied Ctrl+K transaction which would take two consecutive undo transactions to undo—or not: once it's been implicitly converted to Ctrl+K then a single undo should remove both [ transactions. I think he was complaining that this would slow down the program too much; maybe this would have been a credible concern back in the 1960s or 1970s, but not now. Putting up the "wikitext detected" popup doesn't seem to slow down the program. I'm frustrated that just when I thought I might be getting through to him, the conversation seems to have stalled. If Fram has had similar experiences in the past, I can understand why they seem so angry now. Wbm1058 (talk) 14:09, 27 June 2014 (UTC)
Yep, I have about a year of similar experiences. Communicating with some of the VE people can be a very tiring experience. I e.g. still haevn't gotten a decent explanation for why it is, in their opinion, useful to spend a lot of money and hours on an editing tool that after two years is still only used by a minority of people for a small minority of edits, but why it is at the same time not useful to spend some of that time and money on including the few good VE ideas and options (like an improved version of the file selector or the template editor) into the wikitext editor. For some reason, time and money may only be spend on further developing VE, but not on improving wikitext editing in parallel; that should be done by volunteers. While I have no problem with volunteers developing wikitext further (well, they usually do a better job than the paid devs anyway), I don't get the position of the WMF on this; it is as if they are deliberately trying to piss off and alienate the majority of their frequent editors. I'll not mention the MediaViewer or Flow in this context (or the happy exception Echo), where to varying degrees the same happens. Fram (talk) 14:42, 27 June 2014 (UTC)
I'm far from a frequent user of Word, and I think it may be a mistake to assume that most Wikipedia editors are. Actually I have Open Office installed on my computer. I see that there is a "hyperlink" button in Open Office, and when I click on it, up comes a "hyperlink" pop-up interface. But Ctrl+K does nothing, that I can see. Is there a shortcut for "hyperlink" in Open Office? Wbm1058 (talk) 14:20, 27 June 2014 (UTC)
I don't think there's one by default, but you can assign your own keyboard shortcuts in Open Office. Whatamidoing (WMF) (talk) 04:18, 28 June 2014 (UTC)
So are there other "'smart' command re-contextualising" editors that use Ctrl+K by default, or was that just pulled from the sky for VE? I'd like to assign my own keyboard shortcut for wikilinking ;) Wbm1058 (talk) 13:43, 28 June 2014 (UTC)

It sure would be great if VE knew that users typing [[ were trying to create a link, and helped them do it, via the same link box that comes up when you press Ctrl-K. Right now it seems that VE does know they're trying to create a link (thus the "wikitext doesn't work here" popup message) but doesn't particularly help them do it. 28bytes (talk) 00:43, 1 July 2014 (UTC)

Coming from the top vote recipient in our most recent leadership election, your comment here means a lot to me. Thanks. Wbm1058 (talk) 16:26, 1 July 2014 (UTC)
Tracked in Phabricator
Task T69424

If you try to add a non-template namespace transclusion, such as User:Jay8g/sandbox/Template:Airline fleet table/Start, the no TemplateData link goes to the page title with "Template:" added to the front, such as Template:User:Jay8g/sandbox/Template:Airline fleet table/Start, which obviously doesn't work. TemplateData itself also doesn't seem to work right for non-template-space transclusions, as User:Jay8g/sandbox/Template:Airline fleet table/Start's TemplateData was added 11 days ago and it still isn't showing up when adding the template (but is showing up when editing a tranclusion added in a previous edit):Jay8g [V•T•E] 22:05, 26 June 2014 (UTC)

It looks like you forgot to make a null edit to the template. (TemplateData has some maddening quirks.) Try it now. Whatamidoing (WMF) (talk) 04:35, 28 June 2014 (UTC)
I tried null editing it but it still doesn't work. Also, this wouldn't fix the other issue. I wonder if it is trying to check Template:User:Jay8g/sandbox/Template:Airline fleet table/Start for the TemplateData:Jay8g [V•T•E] 18:53, 28 June 2014 (UTC)
It's looking in the right place, because inserting the "template" at User:Jay8g/sandbox/Template:Airline fleet table/Start/doc works. Hmm... I'll mull it over. It shouldn't be this hard. Whatamidoing (WMF) (talk) 03:20, 29 June 2014 (UTC)
I'd like to note that it is showing up when editing existing transclusions, and has been since before the null editing/purging/etc:Jay8g [V•T•E] 15:58, 29 June 2014 (UTC)
I've asked for help here. If we can't figure out how to make this work soon, then I'll need to file a bug. Whatamidoing (WMF) (talk) 01:08, 1 July 2014 (UTC)
Adding 2cents. The template data system seems to know about these templates so its not a null edit problem. You can see this using an api call https://en.wikipedia.org/w/api.php?action=query&list=pageswithprop&pwppropname=templatedata&pwpprop=title&format=json. The Wikipedia:VisualEditor/TemplateData/List page which is generated from this call list both the User:Jay8g/sandbox/Template:Airline fleet table/Start and User:Jay8g/sandbox/Template:Airline fleet table/Start/doc. The first would not be in the list if it was a null edit problem.--Salix alba (talk): 07:55, 1 July 2014 (UTC)
Is this T54609? --Krenair (talk • contribs) 17:19, 2 July 2014 (UTC)
Not exactly. With bug 52609, when you added a template that wasn't in the template namespace, then VisualEditor would put {{Template:User:Jay8g/sandbox/Template:Airline fleet table/Start}}. This is adding the template correctly to the article, but not finding the TemplateData. It might be the same sort of error, but it's technically a separate bug (now T69424). Whatamidoing (WMF) (talk) 18:09, 2 July 2014 (UTC)

Focus issues after adding parameters in template dialog

Tracked in Phabricator
Task T69427

After adding a parameter in the (advanced) template dialog, the focus briefly shifts to the previously added (edited) parameter before going to the one just added. This has led to me occasionally (about one in ten parameter additions) typing (generally just one character) in the wrong box:Jay8g [V•T•E] 02:26, 28 June 2014 (UTC)

I'm not able to reproduce this in Safari 6.1.4 or Firefox 30 on a Mac. We had a similar problem (minus the "briefly" part) in Firefox a few months ago. Can you tell me what your web browser is again? Whatamidoing (WMF) (talk) 04:08, 29 June 2014 (UTC)
Firefox 30, Windows 7. I'm not surprised its hard to reproduce--I would type something immediately after clicking the parameter button and it would only happen occasionally:Jay8g [V•T•E]
Thanks. I've reported it as T69427. Whatamidoing (WMF) (talk) 18:15, 2 July 2014 (UTC)

External link dialogue won't allow display text over the URL

I can't work out, using the visual editor "link" icon, how to make display text rather than just showing the raw URL as the link. I'm sure there used to be a neat dialogue for this but it's not immediately visible now. Wittylama 01:04, 2 July 2014 (UTC)

Hi Wittylama,
If you're adding a new link, then do this: First, type the label you want. Second, select that label and add the link to it.
If you're editing an existing link, then just change the text of the link, as if you were changing any other word.
There are some limitations to this system (changing the link and the label at the same tie requires two separate actions), but this works all right for most purposes. Whatamidoing (WMF) (talk) 19:06, 2 July 2014 (UTC)

New England

Here's what happened when I tried to edit New England using VE. I clicked Editbeta and four blank lines appeared before the lead paragraph. I positioned my cursor at the beginning of the lead paragraph (to the left of the "N" in "New England") and pressed Backspace a few times to delete the blank lines:

  • the first backspace appeared to do nothing
  • the second backspace deleted one of the four blank lines
  • the third backspace deleted the lead paragraph (!)
  • subsequent backspaces did nothing.

Windows 7/Firefox 30.0, reproducible each time I tried. 28bytes (talk) 00:32, 1 July 2014 (UTC)

Yes, I get the same (also W7 FF30), so not some 28bytes-specific problem. Note that the second backspace, which only looked as if it removed a blank line, in reality removed the File:Chestnut Street Salem, which is also unwanted (but already mentioned) behaviour... The third backspace removed some more images and moved the first paragraph inside the infobox, believe it or not, and all subsequent backspaces were edits inside the infobox! Fram (talk) 07:33, 1 July 2014 (UTC)
Do either of you know why "the infobox" is still a table very similar to when it was added in 2006, rather than a proper, non-subst'd infobox template?
The contents of the first section are:
  • an {{about}} template
  • two "invisible" templates: {{Use mdy dates}} and {{pp-move-indef}}
  • the "bizarrely non-standard" (to quote BKonrad in the article history) table masquerading as an infobox
  • three images, each with their own line breaks
  • one hidden HTML note
  • a blank line
  • the text of the lead
One of the four blank lines is VisualEditor's top-of-page slug, which cannot be removed (because otherwise you wouldn't be able to add a new paragraph, image, or template above the first line). The other three are due to the line breaks after the images.
The first backspace appears to do nothing because it selects the third image. You can't see this, because it's hanging two screefuls below the top of the page. The second backspace delets that image, and also the blank line that follows the image in the wikitext. This is why it looks like backspacing removed the blank line.
That backspace also causes both of the remaining images in lead section to be selected. It's actually selecting all the visible/non-formatting content from after the last character of text at the end of the table through and including the end of the second image, but it displays as selecting all of this plus the entire body of the lead, because the selection highlight is showing you both the elements that are selected and the location of the wikitext that's selected, i.e., from almost the top of the page through the bottom of the section (*grumble*). The third backspace deletes all the selected material, which has the effect of merging the first paragraph of the lead with the last "paragraph" of the table. Subsequent backspaces delete content from the table—which, again, you can't see, because it's below the scroll on your screen, so it looks like they "do nothing".
If you open the article now, you'll see fewer blank lines, because I moved two of the images to relevant sections of the article.
I think that this is more than one bug. It may take me a while to figure out how to split them up. Whatamidoing (WMF) (talk) 19:01, 2 July 2014 (UTC)
Thanks, both, for digging into this further. No idea why the infobox is a bare table. 28bytes (talk) 19:17, 2 July 2014 (UTC)

Missing reflist

The wiki software is complaining in big red letters that some "{{reflist}}" is missing. It doesn't comprehend that I [probably] have no idea what markup even is. It should give instructions on adding a reflist using visualeditor. Gryllida (talk) 09:11, 1 July 2014 (UTC)

That's something that has to be changed by the local community. Whatamidoing (WMF) (talk) 19:03, 2 July 2014 (UTC)
What local community? Isn't making this message different for source and for visual editor a MediaWiki thing? Gryllida (talk) 22:21, 2 July 2014 (UTC)
MediaWiki (the software) does not ever tak about {{reflist}}, which is the creation of the English Wikipedia. Any message that mentions {{reflist}} rather than the MediaWiki core component, <references />, is a local message. In this case, I believe you're looking at MediaWiki:Cite error refs without references (edit the page to see the message). Changes to that can be made by any local admin; User:Gadget850 was the last one to do so for this message. Changes can probably be proposed on the message's talk page or at some general tech-oriented discussion page, like WP:VPT. Whatamidoing (WMF) (talk) 22:27, 3 July 2014 (UTC)
All of the Cite error messages on the English Wikipedia are customized and include links to help pages. I haven't been using VE but it looks like I need to try it to update the help pages.  Gadget850 talk 02:58, 4 July 2014 (UTC)
And now I see why it is confusing when using VE. In normal editing you can preview and immediately see that the reference list is missing. If you select Insert → References list, then it inserts the <references /> tag and the only option is for a group but it does show the reference list. If you Insert → Template and select Reflist, then you can set all of the template options, but it does not actually show the reference list and you can't see where the template is actually located. But if you don't add any of the reference list markup, then no error is shown until after saving.
The use of {{reflist}} has become more common than the use of <references /> and the documentation on all the help pages reflects this. I will have to think about this a bit.  Gadget850 talk 11:57, 4 July 2014 (UTC)
Most uses of the reflist template are just the plain template, using none of its options, and could be replaced with the plain tag. We'd get a slight performance boost. Back in the day, I preferred reflist because it changed the font. For the last couple of years, {{Reflist}} and {{Reflist}} have produced identical results. But we still have the template in situations like the article wizard, for these outdated reasons.
But that still wouldn't help the user of VisualEditor, or anyone who is new to the English Wikipedia (but not to MediaWiki software): people who don't know wikitext won't understand a message talking about wikitext. I'm not sure how to solve that problem. We've talked about making VisualEditor complain (e.g., upon attempting to save), which would minimize the problem; perhaps that would be a good approach. Whatamidoing (WMF) (talk) 18:44, 4 July 2014 (UTC)
The error message is MediaWiki:Cite error refs without references.
What can we do on the linked help page that will aid the 37,106 editors using VE? --  Gadget850 talk 11:50, 5 July 2014 (UTC)
With the deployment of 1.24wmf12 on Jul 10, missing reference markup will no longer show an error; the reference list will show below the content.[1] Thus, this error should no longer be experienced after deployment. --  Gadget850 talk 09:25, 7 July 2014 (UTC)
Thanks for posting this; I'd just seen it in Tech/News yesterday. Our ideas have been overtaken by events.
I like your suggestion at the bug for a new maintenance category. Whatamidoing (WMF) (talk) 17:56, 8 July 2014 (UTC)

Tab-swapping script

Does anyone know if there is a good user script for swapping the tab orders (Edit+Edit source vs Edit source+Edit)? I'm thinking of people who do a lot of interwiki work. If you get used to en.wp's order but do some editing at other places, then you might like to keep en.wp's order everywhere (or the other way around: if you work mostly at 99% of the Wikipedias, then en.wp's order is backwards from what you're used to). Whatamidoing (WMF) (talk) 21:43, 8 July 2014 (UTC)

Templatedata for cite book

I just added editor2 params to the template data for cite book. They don't show up for me in the VE template dialog; is this a case where a null edit is needed to make them appear? Mike Christie (talk - contribs - library) 14:41, 3 July 2014 (UTC)

@Mike Christie: Yes; have done so and it now appears to be working. Sorry! Jdforrester (WMF) (talk) 16:24, 3 July 2014 (UTC)
Great, thanks. I will add the editorN params too, later, and drop a note here when done; I won't need them myself but someone will. Mike Christie (talk - contribs - library) 16:26, 3 July 2014 (UTC)
The new TemplateData tool is live now. If you haven't tried it out, then I can recommend it. It doesn't yet support "suggested" parameters, but for getting the basics sorted, it's pretty good. Just go to the template's /doc page, edit the page, and look for the new button on the upper left. Whatamidoing (WMF) (talk) 22:55, 3 July 2014 (UTC)
I just tried that on Template:Cite book/doc and I don't see a button -- is there anything in prefs that might make it fail to appear? Mike Christie (talk - contribs - library) 23:13, 3 July 2014 (UTC)
Mike, click here, and then wait a couple of seconds. You should get a gray button in the upper left that says "Manage template documentation". It will appear immediately below the title =Editing Template:Cite book/doc= and above the statement "This is the documentation page of the template Cite book." If that isn't working, then please click here and see if you have the same problem on MediaWiki.org, or try it in a "private browsing" window, if your web browser supports that.
Whatamidoing (WMF): I see it now, but I didn't when I tried the other day. Not sure what the difference is. I will see about adding the missing editorN params for cite book. Mike Christie (talk - contribs - library) 01:01, 5 July 2014 (UTC)
Addendum: I just discovered that if I go to the link you give above, I see the button; if I go to that page and click "Edit source", I don't see the button. The URL appears to be identical in both cases. Any idea what could cause that? Mike Christie (talk - contribs - library) 01:26, 5 July 2014 (UTC)
Weird (and bad; bug reports for intermittent problems are hard to resolve). I've had it take a second or two to appear. Do you think that when it wasn't there, that it might have been running a little slow/perhaps timed out? Whatamidoing (WMF) (talk) 03:28, 5 July 2014 (UTC)
No, it's definitely just not there. I just noticed that another difference between the two pages is that when I click on the link you provided, I get the toolbar that shows B for bold, I for italics, and so on, at the top of the wikitext editing textbox. I don't normally see that when I edit, so I assume this is indeed a prefs issue. I can't spot the gadget that causes that to appear, so I can try it; do you know what pref corresponds to that? And why would it appear when I click on that link, but not on any other page I edit? Mike Christie (talk - contribs - library) 13:39, 5 July 2014 (UTC)
Mike Christie, which link did you click on? I posted https://en.wikipedia.org/w/index.php?title=Template:Cite_book/doc&action=edit and https://www.mediawiki.org/w/index.php?title=Template:Sandbox/doc&action=edit
Were you in a "private browsing" window when you saw the other edit window? Private browsing windows treat you like a logged-out user: no prefs and no scripts. Whatamidoing (WMF) (talk) 18:05, 8 July 2014 (UTC)

Templates for TemplateData

Tracked in Phabricator
Task T69677
Whatever we do for cite book should be replicated across the Citation Style 1 series. Can you put TemplateData into a template? --  Gadget850 talk 12:00, 4 July 2014 (UTC)
Gadget, I'm not sure if it can be template-ized. I'll ask. Whatamidoing (WMF) (talk) 18:49, 4 July 2014 (UTC)
I updated the template data to have the editor3 through editor9 params, but as before it seems that a null edit is needed. Whatamidoing (WMF), can you oblige? Mike Christie (talk - contribs - library) 01:41, 5 July 2014 (UTC)
No, I'm not an admin. But there are a few who usually watch this page, so perhaps someone else will. Whatamidoing (WMF) (talk) 03:28, 5 July 2014 (UTC)
TemplateData certainly should be able to be template-ized. A template is, in effect, just a transclusion. It is already transcluded from the /doc page to the template page.
I have directly confirmed that a purge of the template page is insufficient for the API to serve the new TemplateData. More info at Help talk:Citation Style 1/Archive 5#Cite book editor2 template data.
I have started the section Help talk:Citation Style 1/Archive 5#TemplateData for citation templates. I would suggest that we use that thread for any discussion about having TemplateData available for all CS1 templates. — Makyen (talk) 13:58, 5 July 2014 (UTC)
@Gadget850 and Makyen: I asked about templatizing TemplateData, and the answer was first yes, and then (presumably after further discussion with the team) is now no. If you get it working, then of course please let me know, but the team currently does not expect this to work. Whatamidoing (WMF) (talk) 18:05, 8 July 2014 (UTC)
(Duplicated from VPT):You can use templates to translude portions of the TemplateData JSON object. You do have to use something like {{#tag:templatedata|Your templates here}}. I have set up an example at {{Ref supports}}. The resulting TemplateData can be seen here. The example transcludes separate portions of the template data JSON from 5 subpages onto the Ref supports/doc page which is then transcluded, using {{documentation}}, onto the template page. — Makyen (talk) 22:09, 8 July 2014 (UTC)

Just done a null edit on {{cite book}}. Note that and many other template pages now use the Wikipedia:Template editor permission. If you plan to do a lot of template data work you can apply to have that bit set. This is a reasonably easy process.--Salix alba (talk): 14:37, 5 July 2014 (UTC)

Thank you. Unfortunately, I had to go do other things so I was not able to test until a few hours later. It was updated at that time. — Makyen (talk) 22:09, 8 July 2014 (UTC)

Citing by PMID

The visual editor is great, but the citation tool would be more helpful if I could just paste in a PMID for a journal article as can be done in citation tool of the source editor. Currently I have to switch back to the source editor to add my citations. Jonsprofile (talk) 08:40, 13 July 2014 (UTC)

Hi Jonsprofile,
I agree, and they're working on it. If you'd like to try out a very early, guaranteed-not-to-be-stable version of VisualEditor's citation filler, then please let me know. I got this citation yesterday by pasting the PubMed URL into it. Whatamidoing (WMF) (talk) 17:37, 14 July 2014 (UTC)

Image replacement overwrites thumbnail size with maximum image size

Bug report VisualEditor
Mito.money Please app{}
Intention: Replace an image in an article
Steps to Reproduce: #Clicked an image while in VisualEditor and clicked edit icon on image
  1. Navigated popup to "replace image"
  2. Replaced image with one found by searching for filename of desired image
  3. Make no other changes to captions, characteristics, etc of image.
  4. Reproduces when replacing same image with other images.
Results: Image appeared in VE editor at very large size. Wikitext shows that size of image thumbnail is now a square with side of the longest dimension of the original image.
Expectations: The replacement image would inherit the thumbnail size of the image I was replacing.
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Rocky_Mountaineer&diff=prev&oldid=616905078
Web browser Chrome
Operating system Win7
Skin
Notes:
Workaround or suggested solution

The Land (talk) 13:32, 14 July 2014 (UTC)

Thanks for this note, The Land! This definitely wins a bug report, which I'll have to file later today. But I've already told the dev whose specialty is media handling, and she's looking into it. With luck, this will get fixed in time to join the usual deployment train on Thursdays (which might mean reaching the Wikipedias next Thursday, depending on the details). Whatamidoing (WMF) (talk) 17:42, 14 July 2014 (UTC)

Insert ref

What's happened to the "reference" option in the "Insert" pulldown? It used to be possible to add a ref by clicking on insert and choosing "Reference"; now that option has disappeared. Is this a bug or an intentional change? Mike Christie (talk - contribs - library) 14:35, 15 July 2014 (UTC)

From the last Tech News: "The reference tool that adds empty <ref>...</ref> tags is now at the bottom of the Cite menu, below references that use templates like {{Cite web}}." By that, they mean Cite → Basic. --  Gadget850 talk 16:00, 15 July 2014 (UTC)
Aha. Thanks! Mike Christie (talk - contribs - library) 16:02, 15 July 2014 (UTC)
The hope is that putting everything in one place will make more sense (at least for people who didn't already know where to find it in the old model), and also that it will make citations more prominent for projects that don't use citation templates or haven't yet configured citation templates. Whatamidoing (WMF) (talk) 19:04, 16 July 2014 (UTC)

Editing a section

Tracked in Phabricator
Task T50429

Please, as I mentioned two times already, when I'd like to edit a section, this program should allocate an edit box for that one section, not for the entire page. Gryllida (talk) 03:16, 26 June 2014 (UTC)

I understand why the VE team has no plans to do this, but I also understand why some editors would like this -- for large pages, even if there's no savings in time, it's nice to restrict the view to just the area to be worked on. A workaround occurred to me: how about allowing a user to set a preference called something like "limit view to section in VE". If this were set, and the "edit beta" link were clicked for a section, VE would edit as it does now, but it would only display the section clicked. In other words, there would be no need to change the way VE parses, or operates; it would be editing the entire page. It just wouldn't display it all to the user. Would this be possible? Mike Christie (talk - contribs - library) 12:54, 26 June 2014 (UTC)
That seems like a great idea. -- Ypnypn (talk) 13:43, 26 June 2014 (UTC)
I don't understand why the VE team has no plans to do this. Having an entire article appear as an editable area when I want to focus on just one section is the major reason why I'm not using VE for generic editing. What goes on internally is completely irrelevant to editors. Their, our, requirements for working comfortably should be put first. — Scott • talk 15:01, 26 June 2014 (UTC)
Although I think this would be a good enhancement, I would like the current behaviour to continue, at least with a preference setting. I've discovered that I frequently take advantage of the fact that VE edits the entire article every time -- when I notice an error at the end of a section, I click the "edit beta" button at the start of the next section, and don't have to scroll up. Mike Christie (talk - contribs - library) 18:11, 26 June 2014 (UTC)
That seems like a great idea. (Sorry for plagiarizing the message, but I do concur. :P). Gryllida (talk) 00:33, 27 June 2014 (UTC)
I agree, there's no reason for this not to be a feature. Darylgolden(talk) 00:39, 27 June 2014 (UTC)
Daryl, the reason that it hasn't been implemented is that editing a single section would be paradoxically slower than editing the whole page.
Scott, I agree with you about the problem of focus. If that focus cost, say, an extra 10% or 20% to open the page for editing, would it be worth it?
Mike, I'm adding your suggestion of "faux section editing" to the bug report. Whatamidoing (WMF) (talk) 04:23, 28 June 2014 (UTC)
I definitely believe so. If you could make it so that the editor interface appears in the section with the rest of the article still displayed above and below it, I would love you. That would solve one of the oldest annoyances there is - having to have a second tab with the rendered article in to check while you're editing one section. Allow inline section editing and you make a dramatic workflow improvement for just about everyone. It would also look hella modern. — Scott • talk 11:32, 28 June 2014 (UTC)
I agree. @Whatamidoing (WMF):, thanks for adding that idea to the bug report; I just added a comment requesting the preference flag. This is a feature I actively don't want (though I can see why others would like it) so I think it should be optional. Mike Christie (talk - contribs - library) 11:52, 28 June 2014 (UTC)

There is also a subtle similar feature for another extension: an "edit [beta]" button for a code snippet like this one. Having CodeEditor show an edit box just for the snippet and not for the entire page would make sense. I think there is a bug for this (bug 60438), and for making it work without page reload (bug 61056).

On the former, there is a comment from TheDJ: “The biggest problem is that we need to make sure not to implement everything a dozen times (live preview, editpage, visual editor and inline code editor).”. Maybe VisualEditor, after learning to edit individual sections, should learn to plug CodeEditor into its edit area to resolve both these bugs. Just a thought. --Gryllida (talk) 23:15, 27 June 2014 (UTC)

Quotes:

Mike Christie has a suggestion: Edit the whole page, but only display the chosen section. by Mike Christie (on the bug)
the reason that it hasn't been implemented is that editing a single section would be paradoxically slower than editing the whole page. by Whatamidoing (earlier on this page)

This raises the question of someone pretty please looking at the thought about editing code snippets. Please also try to explain the paradox. Making whole page editable is ugly; the rest of the page should be visible while editing a section, in my view. Gryllida (talk) 03:37, 30 June 2014 (UTC)

I'm curious to know what benefit you would see from this. The only difference between what you're proposing and the current behaviour of VE is that if you were to actually click in one of the other sections and attempt to edit it, you would not be able to. Why would this be an improvement over the current situation? Mike Christie (talk - contribs - library) 10:10, 30 June 2014 (UTC)
I would be able to have two editable areas on a page. Gryllida (talk) 23:17, 30 June 2014 (UTC)
Because I wouldn't have to upload that much content. The API has means to edit a single section and VE should not kill it. Gryllida (talk) 23:25, 30 June 2014 (UTC)
I guess I either don't understand your answer, or I don't understand the original suggestion you made. What I thought you were suggesting was that VE should allow a situation where all sections are visible, as they are now, but only one section is editable -- that is, if you click in another section, you can't make changes to it. It sounded like you thought that's what should happen in VE if you clicked "edit beta" against a specific section. If that's really what you were suggesting, my question is: what benefit does that give an editor? There's no additional space on the screen as a result; there's no ability to have two separate editable areas on that page; there's no difference in the parsing that VE must do to the page. Why would an editor want that? I really think I must have misunderstood you. Mike Christie (talk - contribs - library) 00:23, 1 July 2014 (UTC)
Maybe I should write a FAQ for this. The wikitext editor does what you might call faux section editing—you just deal with the section, but you're missing some features as a result. Here is one of the simpler problems that faux section editing creates in VisualEditor:
  • In the wikitext editor, if you open a section, and you want to re-use a reference that is defined in another section (including list-defined references), then you take that ref name out of your own human brain and type it in: <ref name=Whatever />.
  • In VisualEditor, if you open a section, and you want to re-use a reference that is defined elsewhere, then VisualEditor takes that ref name out of the other part of the document, and types it in for you.
  • Problem: If you're editing Section #2, and the ref is defined in Section #4, and VisualEditor has not actually read Section #4 (because you told it to only read the source code for Section #2), then you cannot re-use the reference and cannot complete your editing task.
NB that there are also other problems, some of which are familiar complaints to anyone who uses section editing frequently, but this one example should be sufficient to understand why this is a bigger problem in VisualEditor than in the wikitet editor. We'll leave it with the oversimplified statement that faux section editing is a problem, because it doesn't allow editors to do their editing.
True section editing—in which you read everything, but then discard all the things that are irrelevant (e.g., images that don't extend into this section)—solves this problem. However, it is unavoidably slower. Here's the current system, which most advocates for section editing have already deemed to be too slow:
  1. Send everything to your computer (two seconds).
  2. Process everything locally (five seconds).
  3. Make your change (however long you want).
  4. Send everything back (three seconds).
Here's what true section editing would do:
  1. Send everything to your computer (two seconds).
  2. Process everything locally (five seconds).
  3. Throw away three-quarters of what you just processed (two seconds).
  4. Make your change (however long you want).
  5. Send everything back (two seconds).
There's a net loss to speed here.
Also, before anyone asks again, section editing hasn't prevented edit conflicts for about eight years now. Whatamidoing (WMF) (talk) 00:54, 1 July 2014 (UTC)
That does lead to the question - what's the plan for improving edit conflict handling, and if there is no plan, why not? We're so far behind the state of the art in dealing with those that it hurts. Note that this isn't a VE-specific question. — Scott • talk 09:50, 1 July 2014 (UTC)
I don't know what the plan is, but I totally agree with you. I'll ask around. My initial guess is "not during the next three months", because they've already packed more than three months' worth of work into the official list for the next quarter. Whatamidoing (WMF) (talk) 17:59, 2 July 2014 (UTC)
Scott, the story appears to be this: Currently, MediaWiki handles edit conflicts at the level of paragraphs (which is where it seems to have stood since about 2006 or 2007; before then, it was at the level of sections). Therefore, if you change paragraph 1, and I change paragraph 3, then all's well anyway.
The officially planned improvement is that VisualEditor will (someday) develop real-time editing capabilities, which will mostly resolve edit conflicts, but presumably this helps only people who are using VisualEditor. Doing this is not on the plan for the next year, and I would hesistate to guess which year this difficult work would actually be reasonably finished in. There is also a plan for Parsoid to handle edit conflicts at the sub-paragraph level, which I believe should reduce (but not eliminate) edit conflicts. This plan is less well-explained but may (probably will) happen sooner. However, again, it's not clear how much value this will provide to people who are using the wikitext editor in the short term. In the long term, it may help them just as much as anyone else, because the long-term (and somewhat tentative) plan is for pages to be stored as HTML5+RDFa files (ready to read instantly, but would have to be translated to wikitext before editing), rather than as wikitext files (which are ready to edit instantly, but have to be translated to read—the justification is that people do a lot more reading than editing). Parsoid is the tool for converting between those two formats, so if this plan is implemented, then that would reduce edit conflicts for people using the wikitext editor. Finally, Flow's structured discussion system should reduce or nearly eliminate edit conflicts, on the grounds that most edit conflicts are due to two people replying simultaneously, rather than both of us trying to edit your previous comment simultaneously.
The realistic bottom line, I think, is probably that the edit conflict situation will be improved, but not completely resolved in a couple of years. Whatamidoing (WMF) (talk) 17:51, 8 July 2014 (UTC)

Interface

About interface, I would leave all 3 options:

  • Entire page editable;
  • One section editable, rest of page visible;
  • One section editable, rest of page invisible (in a popup or separate page; most consistent with old behaviour, but also most annoying).

I don't care which of the last 2 options you make available, but I would like VE to just please stop processing or uploading the entire page. As mentioned earlier in this section, I may have wanted to edit a very small thing, a section typo or a small code snippet. Gryllida (talk) 09:35, 1 July 2014 (UTC)

Making the rest of the page visible or invisible isn't going to stop VisualEditor from processing and uploading the entire page. The only way to stop loading and processing the entire page is for all of the communities to declare that they really do want VisualEditor to be deliberately broken in ways that will surprise most users during section editing, e.g., making users unable to re-use references or edit templates that appear to be in that section, but are actually elsewhere. I haven't yet seen anyone say that dropping editors into an editing session with no clue whether they'll be able to make the change that they need to make is a desirable situation.
Would your practical problem be solved by making VisualEditor's opening much faster? Whatamidoing (WMF) (talk) 17:59, 2 July 2014 (UTC)
"Making the rest of the page visible or invisible isn't going to stop VisualEditor from processing and uploading the entire page." is stupid in my view, the API supports this.
"The only way to stop loading and processing the entire page is for all of the communities to declare that they really do want VisualEditor to be deliberately broken in ways that will surprise most users during section editing, e.g., making users unable to re-use references or edit templates that appear to be in that section, but are actually elsewhere" is something you can solve by making VE or API or Wikidata aware of the list of references used, so that they're accessible from within a section edit box.
Please do not blend the two problems together; this feature request suggests a need in doing some more work first, but such work would be useful to people who are using the classic source editor too (which does allow editing sections separately). --Gryllida (talk) 22:24, 2 July 2014 (UTC)
something you can solve by making VE or API or Wikidata aware of the list of references used... yes, we can do that. We do that by uploading and processing the entire page, which is exactly what you said that you don't want VisualEditor to do.
It's not that complicated: There are, because of the unstructured way that editors choose to write pages, going to be refs scattered throughout the entire page. Either (a) you read the entire page to find all the refs, or (b) you don't read the entire page and don't find all the refs. It is, in the end, your choice which one we recommend to the devs, but the option of "don't read the entire page, but (somehow) still know the contents of the entire page" is not actually plausible. Whatamidoing (WMF) (talk) 22:13, 3 July 2014 (UTC)
Hi Whatamidoing. Why do I need to process the entire page to know this information? I believe it should be stored with the page, like the flagged-or-not status with flaggedrevs. —Gryllida (talk) 08:52, 13 July 2014 (UTC)
You need to process the entire page to find all the refs because, for better or worse, all of the refs are currently typed into the text of the page.
There have been proposals to have this information stored elsewhere (e.g., at Wikidata), but this has not happened yet. Whatamidoing (WMF) (talk) 17:26, 14 July 2014 (UTC)
Whatamidoing (WMF), Would you consider working on that please? I recall the WMF Engineering Teams are good at collaborating and sharing their work. Gryllida (talk) 22:47, 14 July 2014 (UTC)
It's on the radar, but it's a long way off, and requires substantial support from both the Wikipedias and from Wikidata. James F is one of the key proponents inside the WMF. I believe that structured data for Commons files has been prioritized over it (in the sense that "priority" means "what you do first", not "more important"). Whatamidoing (WMF) (talk) 19:09, 16 July 2014 (UTC)

Referencing in a section

For the references issue described by Whatamidoing, remembering from brain is the current way. VE can do it client-side (as you say). It doesn't for me: copy-pasting [2] into another point in an article makes it appear as some other number.

Being able to pull references list from API or Wikidata is a feature request I believe, potentially preferred over doing it client-side. It could address Whatamidoing's concern about referencing within a section nicely. Gryllida (talk) 09:35, 1 July 2014 (UTC)

Copying and pasting refs doesn't work at the moment (it will eventually, but not yet). To re-use a reference, place your cursor where you want to add the duplicate. Go to the Insert menu and choose "Reference". In the lower left corner, click the "Use an existing reference" button. Choose the ref you want to re-use from the list. Whatamidoing (WMF) (talk) 17:59, 2 July 2014 (UTC)
Acknowledged. Is this in the FAQ perhaps? I would be happy to translate some of VE documentation by the way, I will have a look. --Gryllida (talk) 22:25, 2 July 2014 (UTC)
It's in the user guide. The central copy is at mw:Help:VisualEditor/User guide. NB that most of the screenshots will change in the next few weeks, and some of the text will change then, too. We've been pretty chary of invalidating translations, so the 94% completion rate for the Russian version may be overstating the case significantly. Also, one of the other persistent problems has been that translators do good work, but then the updated versions don't make it out to the relevant communities. So if, after doing any translation work (VisualEditor or otherwise), you wanted to take a few minutes to copy it out to local wikis where editors could see it, then that would also be very helpful. Whatamidoing (WMF) (talk) 22:21, 3 July 2014 (UTC)

Timing

Saving the entire page in VE is dog slow (as is in the classic source editor) simply due to the amount of data I need to send.

Consider mobile applications — I see VE going mobile very soon. Scale it down to slow Internet.

For the sequences of seconds, surely sending (or processing) everything sounds redundant? Gryllida (talk) 09:35, 1 July 2014 (UTC)

I believe that most pages can be saved in about three or four seconds, although it depends on the page, your internet connection, and how busy the servers are. My sandbox is a fairly complicated page and I have a cheap internet connection. I made a change in VisualEditor, and it took about five seconds to save that page just now. I made another change in the wikitext editor, and it took about seven seconds to save (I'd assumed that it would be the same, but it was noticeably slower). As a result, I'm not sure that changing VisualEditor is going to help. What might help is Operations' increased emphasis on performance standards. Whatamidoing (WMF) (talk) 17:59, 2 July 2014 (UTC)
We are discussing the "process everything" in another section now.
On mobile Internet, saving a page in the classic source editor takes up to a minute for me easily. Gryllida (talk) 22:27, 2 July 2014 (UTC)
That sounds painful. What's your mobile platform? If it's Android, have you seen the new app? Whatamidoing (WMF) (talk) 22:14, 3 July 2014 (UTC)
WhatamidoingMobile Linux (Maemo) and Firefox OS. No, not Android. — The problem is bandwidth and the huge amount of kilobytes the entire page contains compared to a section. —Gryllida (talk) 08:54, 13 July 2014 (UTC)
I wonder how the page size compares to the overhead for editing (opening the editor itself). Whatamidoing (WMF) (talk) 17:32, 14 July 2014 (UTC)

Line appearing above "beta"?

Bug report VisualEditor
Mito.money Please app{}
Intention: To make the line appear below "beta".
Steps to Reproduce: Go to any random page.

Hover over Editbeta.

Results: Edit has a line under it, while beta has a line above it.
Expectations: That the line would appear below "beta".
Page where the issue occurs Any page that you can use VisualEditor on
Web browser Firefox 30.0
Operating system Windows 7
Skin Vector
Notes: I usually use IE11 but VisualEditor doesn't work on that.
Workaround or suggested solution none

Eman235/talk 23:21, 15 July 2014 (UTC)

Thanks for your note. This is a known bug. It isn't actually a bug with VisualEditor itself; it's a problem with the MediaWiki skin that appears whenever you have superscripted text in that situation. The only realistic solution is to remove the "Beta" label. Whatamidoing (WMF) (talk) 19:06, 16 July 2014 (UTC)
Which I suppose ought to be removed eventually, at least when it's released to the general public. After all, it won't be being beta tested anymore. Eman235/talk 09:08, 18 July 2014 (UTC)
P.S. there seems to be something wrong with the bug report template -- in the "steps" parameter the first item of a numbered list renders as #lorem ipsum rather than 1. lorem ipsum. (S.A.A. but at 09:13, 18 July 2014 (UTC)) — Preceding unsigned comment added by Eman235 (talk • contribs)
Thanks for the note about the teplate. I don't know how to solve it. The # would need to start on a new line, rather than the first character of the table cell, and it appears that the template strips leading blank lines from the parameter. Whatamidoing (WMF) (talk) 17:48, 18 July 2014 (UTC)

Strange behaviour

I have run into some reproducible strange behaviour; I'm posting a description rather than a bug in case this is something that is already recorded. To reproduce:

  • Edit this rev of the article I was working on.
  • Go to the Bibliographic details section, and at the end you'll see a list of cite book templates. These are a bit messed up because when I realized I was seeing odd behaviour I did an intermediate save.
  • Place the cursor on "Three stories froro", after "fro" and before "ro". Type "m", and a space, and then delete the "ro" by hitting the delete key twice. This should leave the first part of the sentence looking normal: "Three stories from Science ..." but what actually happens is that the first del key deletes the "m " that has just been typed, and puts the "ro" before the cursor, instead of after. The "r" after the cursor does disappear, but the following "o" is still there.

Is this a manifestation of a known bug? Mike Christie (talk - contribs - library) 21:42, 20 July 2014 (UTC)

I should have said: Chrome, Windows 7. I'm now seeing some much stranger behaviour; so strange that I'm wondering if my browser is misbehaving in some way. It's starting to insert random characters as I type. I've restarted Chrome and still see the same behaviour. Before I spend more time on this, would someone mind trying to reproduce what I describe above? If it can't be reproduced it is likely something local to my machine. Mike Christie (talk - contribs - library) 21:52, 20 July 2014 (UTC)
Reproduced (with Firefox, Windows 7). It seems to be an issue with way VE handles the "Delete" key. -- Ypnypn (talk) 22:06, 20 July 2014 (UTC)
Thanks for verifying that. It's not just the delete key; I've been experimenting and I can get bizarre behaviour in other ways. This rev, for example, seems to act up. I've repeatedly been able to get VE into a state where it starts randomly inserting characters without me touching the keyboard -- it appears to go into some kind of loop. This happens after making multiple edits to the same area mentioning above -- I used multiple del, backspace and Ctrl-I keys, as well as double clicking on a word to select it and typing over it. If I can get a keystroke sequence that will reliably reproduce it I will post it here. Mike Christie (talk - contribs - library) 22:22, 20 July 2014 (UTC)
By "delete", you mean the "forward delete" key? That detail may not be important; I also get screwy text changes in Safari in a Mac (which doesn't have a forward delete key).
I think that this is a known bug, but I'll have to sort out which one. I believe that the template (rather than web browser or things like that) is the critical piece. Whatamidoing (WMF) (talk) 17:20, 21 July 2014 (UTC)

Need Video Clip support for Wikipedia:VisualEditor/User guide page

Hi, I always compliment VE team for taking lot of efforts to improve it. The present Wikipedia:VisualEditor/User guide page is too leangthy to read. It needs Video Clip support with screen capture for brief, 'How to' tour. Ofcourse separate ones for each language wiki projects. For example I wrote an intro article about VE on one of Marathi language website cum Web portal but I did not have any video clip or power point to share with.

If not immidiately may be over a period of time, but needs to be added in list of things to be done.

Best wishes Rgds Mahitgar (talk) 14:25, 24 July 2014 (UTC)

Thanks for the suggestion. One of my goals for the next month or so is to re-write the user guide. As of a few minutes ago, almost all of the pictures for dialogs are outdated, too. Whatamidoing (WMF) (talk) 18:03, 24 July 2014 (UTC)

Cite Function

Just wanted to say the new cite function is really good. Red Fiona (talk) 23:52, 25 July 2014 (UTC)

Thanks, Red Fiona. The autofilling mw:Citoid work is coming along nicely, too, so I hope that in a month or two, we'll have some major improvements to it. Whatamidoing (WMF) (talk) 21:46, 27 July 2014 (UTC)
Tracked in Phabricator
Task T70692

The Save dialog should have a link to report a bug.

Bug report VisualEditor
Mito.money Please app{}
Intention: save changes to a page
Steps to Reproduce:
Results: There is no link to report a bug. There is a "leave feedback" item under the ? help link in the editor toolbar, but that's kind of hidden, and it doesn't take you to a real bug report form.
Expectations: There should be a link to open a new window to a bug report form. The link should be explicit that you won't lose what you're doing and that the bug report form will open in a new window.
Page where the issue occurs any
Web browser any
Operating system any
Skin any
Notes:
Workaround or suggested solution google for how to report a bug in the beta editor.

Encyclopedant (talk) 22:45, 25 July 2014 (UTC)

I have put your idea on the list. Thanks for sharing it. Whatamidoing (WMF) (talk) 21:50, 27 July 2014 (UTC)

Changes lost after canceling a Save

Tracked in Phabricator
Task T70693
Bug report VisualEditor
Mito.money Please app{}
Intention: modify text in a section of a page
Steps to Reproduce: Steps:
  1. Enter the beta editor
  2. Insert abc
  3. Click Save
  4. Click Review your changes
  5. Click Return to save form
  6. Click Cancel
  7. Insert xyz
  8. Click Save
  9. Click Review your changes.
  10. Notice that the xyz is not shown.
  11. Click Return to save form
  12. Click Cancel
  13. Notice that the abc and the xyz are both still there in the document draft
  14. Click Save
  15. Click Save page.
  16. Notice that the abc is saved in the page, but the xyz is not.
Results: changes after the first attempt at saving are discarded
Expectations: all changes are saved into the page
Page where the issue occurs any
Web browser Safari 7.1
Operating system OS X 10.9.4
Skin
Notes: reproducible always
Workaround or suggested solution

Encyclopedant (talk) 22:36, 25 July 2014 (UTC)

Thank you for reporting this. Lost-work bugs are always serious. I've filed T70693 and started searching for any devs who might be online this weekend.
Your list of steps is very clear, which I always appreciate. It's possible to reduce them even further: make a change, click save, cancel, make another change, save, scream. (Or, at least, I'd add that last one if it were my work being lost.) Again, thanks for reporting this. Whatamidoing (WMF) (talk) 22:12, 27 July 2014 (UTC)
This has been fixed, and the fix is in production. If it comes back in the future, then please let me know. Whatamidoing (WMF) (talk) 17:24, 28 July 2014 (UTC)

Pawn insanity

Tracked in Phabricator
Task T70691

Edit Hong Kong International Airport#Composition in VE. Click between Asiana Airlines and Air France and add "and". Watch as the article goes insane with pawns and "Air Fr". Text after change pasted in my sandbox. Interestingly, using undo shows this is a series of actions. Firefox 31, Windows 7:Jay8g [V•T•E] 19:46, 27 July 2014 (UTC)

I've been trying to make other edits to this page and keep getting pawns and/or repeated text, pretty much every time I try to edit the text (as opposed to just adding {{convert}}, which seems to be generally sucessful):Jay8g [V•T•E] 20:02, 27 July 2014 (UTC)
If I first break the paragraph, (so that the convert template is in a separate paragraph), it doesn't do it. Also, I have to type (to get a pawn) and the click elsewhere (to get the repeats). I've filed a bug report. Thank you for the message and for saving a copy of the mess it made in your sandbox. Whatamidoing (WMF) (talk) 21:45, 27 July 2014 (UTC)

In this edit, I got a snowman after rearranging (copy and paste) a sentence with {{convert}}. This did not show up in VE itself, and appeared in place of the comma that I had actually added (and that had displayed in VE):Jay8g [V•T•E] 00:23, 28 July 2014 (UTC)

Hi Jay8g, I'd wondered if you'd manage to get snowmen as well. Snowmen are problems with ContentEditable. Would you take a look at T69992 and tell me if you think that might be the same thing? The problem in those diffs are also downstream from a template. Whatamidoing (WMF) (talk) 02:11, 28 July 2014 (UTC)
It seems highly likely:Jay8g [V•T•E] 03:24, 28 July 2014 (UTC)
I've added your note to that bug. There's a chance it will be fixed this Thursday (at MediaWiki; here a week later). Whatamidoing (WMF) (talk) 17:27, 28 July 2014 (UTC)

Piped links?

Am I crazy, or can you not add piped links while editing in VE mode? Ed [talk] [majestic titan] 16:51, 29 July 2014 (UTC)

You can definitely add piped links. Type the text you want to appear (the right side of the pipe) then select that text and click the link button. Then overtype the default text (which is whatever you selected) with the target you actually want. Mike Christie (talk - contribs - library) 17:09, 29 July 2014 (UTC)

IE 11

I managed to get VisualEditor in Internet Explorer 11, although it was in (what I assume to be) HTML mode, where everything was written in IMPACT. Also, there was a message that said "You are using a browser that does not support VisualEditor". Has this ever happened to anyone else? --UserJDalek 04:50, 29 July 2014 (UTC)

It doesn't look like you manaed to save the page. An inability to save is the main reason that IE is disallowed. Whatamidoing (WMF) (talk) 15:31, 29 July 2014 (UTC)
Actually, I didn't make any changes anyway, I only activated it to see if I could. Also I just realized it looks like Nostalgia Wikipedia. --UserJDalek 22:34, 29 July 2014 (UTC)

JavaScript

In the "Beta" section of my preferences, under "VisualEditor", it used to say it wouldn't work in IE, but now it just says it requires Javascript. Does it mean the same thing? --UserJDalek 05:06, 30 July 2014 (UTC)

No. I think that they just tried to simplify the description. It won't work for anyone in any browser, if you've turned Javascript off in that browser. It also doesn't work (yet) in Internet Explorer (although that will change this year, we hope). Whatamidoing (WMF) (talk) 04:48, 31 July 2014 (UTC)

Add a "cancel" button

from ru:Википедия:Визуальный редактор/Отзывы#Кнопка "Отменить"

Perhaps VE need to add a "cancel" button next to the "save page" button. Button cancels all my changes. For now you need to cancel: press tab Article, tab Read, another link or close the browser tab. These methods are not very clear or intuitive. Beginners easier to save his changes, rather than seek how to cancel.

Often happens that a novice makes editing, saving, and then immediately make a new edit to cancel his previous actions (for example).~ Sunpriat (talk) 07:06, 3 August 2014 (UTC)

I see from this that this change was intentional, but I agree it's unintuitive for most users. It's also inconvenient as the read button is not on screen, whereas the cancel button was. I'm surprised to see in the bug description that this was a cause of complexity. Mike Christie (talk - contribs - library) 11:05, 3 August 2014 (UTC)
James apparently didn't put the most compelling argument into the Gerrit description: nobody was using it. It feels a little weird to have it gone (it feels weird to me almost every time they change anything on the toolbar), but it wasn't actually getting used.
(The same is probably true for the wikitext editor: I "cancel" my edits all the time, but I don't think that I've clicked the official cancel link more than once this year.) Whatamidoing (WMF) (talk) 17:46, 4 August 2014 (UTC)

Random nowiki tags added

Please see here. Δρ.Κ. λόγοςπράξις 11:26, 1 August 2014 (UTC)

Δρ.Κ.,
Thanks for your note. It's not a random change. An inexperienced editor screwed up the wikitext formatting for a template, and VisualEditor (well, actually Parsoid) was trying to clean up after the editor's mistake. The tag was added like this:  |section{{editorial}}. VisualEditor doesn't care about "section" parameter being placed uselessly outside the template, but it does know that lines of text should not normally start with a leading space, which can cause <pre>-style formatting and loss of line wrapping.
It would presumably be best to correct the tag so that it actually says {{editorial|section}}, instead of dumping a stray "|section" into the article text. Whatamidoing (WMF) (talk) 17:57, 4 August 2014 (UTC)

Can't reuse a citation if it's been re-used and the original deleted in the same edit session

Tracked in Phabricator
Task T70582
Bug report VisualEditor
Mito.money Please app{}
Intention: I was trying to re-use a citation that I had previously repositioned in that edit session
Steps to Reproduce: 1. Create a citation that exists in only one place. Save the page.

2. Edit in VE and use "re-use" to place another copy of that citation somewhere else on the page.
3. Delete the original use of the citation, so that only the re-used copy of the citation is left.
4. Now try to use re-use to place another copy of the citation elsewhere.
I've reproduced this three times on different articles.

Results: Selecting the citation in the list of citations for re-use does nothing
Expectations: Selecting the citation in the list of citations for re-use should have inserted the citation.
Page where the issue occurs Reproduced in the sandbox.
Web browser Chrome
Operating system Windows 7
Skin Vector
Notes: N/A
Workaround or suggested solution Save the file and then re-use the citation

Mike Christie (talk - contribs - library) 12:43, 3 August 2014 (UTC)

My preferred workaround is to add a 'wrong' citation, remove it, and then add the correct one.
The good news is that Krenair already has a patch written, reviewed, and merged to fix this. The bad news is that the Wikimania-induced code freeze is upon us, so we probably won't see the fix here until 14 August. Whatamidoing (WMF) (talk) 18:02, 4 August 2014 (UTC)

Ref groups

In Visual Editor, a page with footnotes created via <ref group=lower-alpha> or {{efn}} are showing up as [lower-alpha 1], [lower-alpha 2] etc instead of [a], [b] etc. See for example the five footnotes in Transportation in Puerto Rico#Federal_restrictions. This only occurs in-text, the list at the end of the page shows the letters. In case it's relevant, I'm using Vector / Chrome v36 / Win 7. - Evad37 [talk] 05:36, 4 August 2014 (UTC)

Confirmed - in VE edit mode, the format for the footnote numbering is much different than in read mode. (Vector/FF 30.0/Mac OS) -- John Broughton (♫♫) 17:01, 4 August 2014 (UTC)
That's ugly. I wonder if it's fundamentally the same problem as T51346? Whatamidoing (WMF) (talk) 18:06, 4 August 2014 (UTC)

div and bullet list

Tracked in Phabricator
Task T71117
Bug report VisualEditor
Mito.money Please app{}
Intention: edit items of bullet list (*) (ru-wiki)
Steps to Reproduce: #for example: article ru:Борисов#Б (Borisov - Last name), wikitext: 
* [[Borisov, Boyko]] (b. 1959) - Bulgarian politician. . //item1
* {{NL|Borisov, Boris}} //item2

where in item2 name of another articte(also bullet list) as template(ru:Template:NL) argument

  1. click on list item1
Results: # this item1 is highlighted with next item2 as one solid template
  1. if open templateeditor for this highlighted then first item showed as "content" with text
--
[] content
* text first item1
*
--
template block
  1. before item with template can be many usual items, and they all are shown as one "content"
Expectations: items, before item with template NL, can be edited as usual bullet list item, not as content in templateeditor
Page where the issue occurs ru:Борисов, ru:Template:NL
Web browser firefox 31
Operating system
Skin Vector
Notes:
Workaround or suggested solution

Sunpriat (talk) 18:17, 3 August 2014 (UTC)

Hi Sunpriat, and thanks for your note.
I've got an idea about what's happening here. I'm not entirely sure that it can be fixed.
An entire list is "one thing". A template is "one thing". And when you combine the two—when you put a template inside a list—you sometimes get "one complicated thing" instead of two separate things. In this case, you get a complex transclusion. It does not happen with all templates, and I don't know why it happens here. It may be due to the way that particular template was written, or because the template has multiple lines, or because it contains bullet items, or because of some other reason.
I'll file a bug report, but I don't want to get your hopes up too high. This may not be something that can be quickly solved by changing VisualEditor. Whatamidoing (WMF) (talk) 18:28, 4 August 2014 (UTC)

"Cancel" on the save dialog

Tracked in Phabricator
Task T71116

While "cancel" makes sense for most dialogs, on the save form it makes me feel like I am going to cancel the edit, not just close the box, especially since the actual cancel button is gone. With the recent removal of the actual cancel button, perhaps an actual cancel button should be added to the save box. Also, it is annoying that the review changes box has no close button:Jay8g [V•T•E] 15:24, 3 August 2014 (UTC)

Thanks for this note. I agree with you. Any ideas for what it should say? I've thought of "Return to editing" and "Resume editing", but I'm happy to post other suggestions.
I'm not sure what your second request is. The button on the Review changes box is "Return to save form", which closes the box. Do you want a second button that does exactly the same thing? Or do you want to close both the Review changes box and the Save dialog box at the same time? (Pressing the escape key does that.) Whatamidoing (WMF) (talk) 18:14, 4 August 2014 (UTC)
Simply "close" seems to be best due to its simplicity. As for "return to save form", it doesn't really (visually) close anything but simply changes the content of the box. An actual close button (for closing "both") would be simpler. (The fact that the escape button closes the box shows that it really is just one box.):Jay8g [V•T•E] 23:42, 4 August 2014 (UTC)
I'm not sure what the current state is, because they just re-wrote the windows. But previously, I believe that these were separate windows (with "Review your changes" being larger than "Save").
If they put "Close" on "Review your changes", and it closes everything, then that might surprise some users. What do other people think? Whatamidoing (WMF) (talk) 16:27, 5 August 2014 (UTC)
I've confirmed that they actually are separate windows. I don't think that it makes sense for "Cancel" in window #2 to close both window #1 and #2. Whatamidoing (WMF) (talk) 16:39, 5 August 2014 (UTC)
Visually, they aren't separate. The animation when you click the review and return to save form buttons is not that of a window opening and closing but of the same window expanding and contracting. I don't see how a close button that closes what seems like only one window could be confusing. It, on the other hand, is annoying to have to click two buttons, in different places on the box, to simply correct something that you noticed on the review form, and could be construed as confusing that this box (or, more accurately, form of this box) has no close button when all other boxes (and forms thereof) have close buttons:Jay8g [V•T•E] 00:35, 6 August 2014 (UTC)

Adding text next to a cite inside ref tags

Tracked in Phabricator
Task T71498

I'm now working with the new Newspapers.com service, and the citations are supposed to be in the format <ref>{{cite news ...}} {{Open access}}</ref>. I can't figure out how to add the {{tl:Open access}} template (or any other text) to the ref in VE. Is it possible? Mike Christie (talk - contribs - library) 11:36, 7 August 2014 (UTC)

@Mike Christie: You can create references in VE that have multiple templates (or a template and other information). From the Cite menu, select "Basic". Then, in the Reference dialog, on the Insert menu, select Template. After you've created the cite news template, you're back to the Reference dialog, with the opportunity to add another template.
It's also possible, in VE, to add a template (or, for that matter, any other non-parameter information) to an existing Cite news template. It's just not obvious how. The trick is to select the footnote, then ignore the icon that pops up. Instead, go to the Cite menu, and select "Basic". Viola - you're in the Reference dialog. (Given that this isn't obvious, I do wonder if the user interface should be tweaked a bit to enable getting to the Reference dialog more directly. Maybe a small "Open as a Basic cite" option, when the "Cite web" or "Cite news" or similar icon is displayed?) -- John Broughton (♫♫) 16:25, 7 August 2014 (UTC)
Because of T66712, double-clicking the ref (the [1] itself) will open it in the Basic (manual) editor.
John, I know that's been discussed, but I can't find the bug number. I'll put it on my list of things to track down (and/or re-file: I probably haven't met my quote for duplicate bug reports yet this month.  ;-) Whatamidoing (WMF) (talk) 19:21, 8 August 2014 (UTC)

Creating a new template

Tracked in Phabricator
Task T71358

For the New template dialog (Insert menu, then the Template item), the check mark that appears in the list (as one types) is very misleading. For example, I typed “cita”, at which point the checkmark was next to “Citation needed”. I then clicked “Add template” and the dialog showed me I was now editing the “Cita” template, not the template I expected - the one with the checkmark next to it.

Either there should NOT be a checkmark, or if there is a checkmark, clicking on “Add template” should select the template which is checked. But right now the checkmark is worse than meaningless - it's misleading. -- John Broughton (♫♫) 19:58, 7 August 2014 (UTC)

It's now T71358. It will probably get marked as a duplicate (surely this irritating problem has already been filed?), but I couldn't find one that obviously covered this. Whatamidoing (WMF) (talk) 06:19, 10 August 2014 (UTC)

Inconsistent sizing of input boxes in Cite dialog (mini-editor)

Tracked in Phabricator
Task T71508

In my limited testing, I found that most of the time the mini-editor for a cite template (click on an existing footnote using a cite template, then click on the icon) will display overly large input boxes (fields), as shown in the first screenshot. But sometimes it displays smaller boxes (second screenshot), which I think is far preferable. Is the first of these (large input boxes) a bug? (Vector, Mac OS, FF 30.0) -- John Broughton (♫♫) 17:15, 10 August 2014 (UTC)

The Formula input box needs a Cancel button.

Tracked in Phabricator
Task T54462

The Formula dialog (input box?), available via the Insert menu, is lacking a Cancel button. That's a feature of (almost?) all other dialogs. (Pressing [esc] or clicking outside the input box closes the dialog and saves what was input.) -- John Broughton (♫♫) 17:33, 10 August 2014 (UTC)

Confusing pop-up

Tracked in Phabricator
Task T71201

My first experimential edit was an attempt to wikilink a term. An instruction poped up, saying: (You are using VisualEditor - wikitext does not work here. To switch to source editing at any time without losing your changes, open the dropdown menu next to "Cancel" and select "Switch to source editing?".) I could not find the "Cancel" button and as it turns out, it is not revealed until you press "Save page". Most editors would be reluctant to press "Save page" thinking the edit would save. Furthermore there was no "dropdown menu" next to it. I've come to find that the three horizontal bars next to "Save page" actually has the option to switch to source editing, so it seems the entire instruction needs reworked a bit. Thank you.—John Cline (talk) 02:40, 10 August 2014 (UTC)

Looks like nobody checked these messages after they removed the cancel button...:Jay8g [V•T•E] 03:14, 10 August 2014 (UTC)
Thanks for this note. The patch was merged a few days ago, but thanks to the code freeze around Wikimania, it hasn't shown up here. Unfortunately, it probably won't appear until next Thursday. Whatamidoing (WMF) (talk) 06:04, 10 August 2014 (UTC)
Why has the cancel button been removed? I was about to open a bug on that, it seems to me to be an obvious requirement. There is no obvious way on-screen of cancelling an edit. Why would we not let an editor cancel a botched attempt that had gone beyond fixing? SpinningSpark 11:46, 11 August 2014 (UTC)
Use "Escape" to cancel the edit, as in all other programs? Apparently not, here. (See #Link dialog issues, above.) — Arthur Rubin (talk) 15:52, 11 August 2014 (UTC)
I thought we were talking about a cancel button on the main VE editing screen, not dialogue boxes. I think that this is a necessary feature so have opened bug 69406. SpinningSpark 16:39, 11 August 2014 (UTC)
I see James Forrester closed it as WONTFIX: I've added a comment to the effect that I agree it's necessary. @Whatamidoing (WMF): what's the etiquette for re-opening bugs? I would like to reopen that, but am not sure how the dev team expects the community to interact over bug workflow. Mike Christie (talk - contribs - library) 17:30, 11 August 2014 (UTC)
Spinningspark, the "Cancel" button was removed because almost nobody used it—not on the wikis, and not in formal user testing with newbies (some of which is done via usertesting.com, if you're curious). They wanted to have more space on the toolbar (e.g., so that when you zoom in, it doesn't take over half your screen so soon). If feels a little weird to have it gone, but I don't believe I've ever clicked it except for testing it, and I "cancel" most of my edits in VisualEditor.
Mike, the etiquette is absolutely no edit warring, but you can re-open a bug if (a) it was fixed, and it's a regression; (b) you believe that it was closed by accident; or (c) you believe that the person making the decision completely misunderstood the question. In this case, none of that applies, so you should leave it closed. The official follow-up recommendations are e-mail to the product owner and/or person closing it (James F is both in this case) or to send e-mail to one of the tech mailing lists, like wikitech-l. Whatamidoing (WMF) (talk) 17:56, 11 August 2014 (UTC)
Also, Mike, if you need to 'cancel' an edit and you don't want to scroll back to the top of the article, you can use the WP:Keyboard shortcuts for "switch to content page" (it's Ctrl+⌥ Option+c on my Mac) to get back to read mode. Whatamidoing (WMF) (talk) 18:01, 11 August 2014 (UTC)
Aha. I didn't know about that; that makes me very happy. Now I don't care about the cancel button. (It's Alt-Shift-C on PCs.) Mike Christie (talk - contribs - library) 18:06, 11 August 2014 (UTC)

Incremental edit summary

It is not possible to write in the edit summary while actually editing. If four different things are done in one edit, the first one will probably be forgotten by the time it comes to filling in the edit summary. This feature is avaiable in the source editor and I don't see why it should not be retained in VE. It is something commonly required. For instance deleting inappropriate entries on a list: it is easy to record the entries deleted in the edit summary as one goes through them, but a complete pain to do in one hit afterwards. I know this problem has been raised before by other editors but I'm not seeing it in Bugzilla so have opened bug 69393. SpinningSpark 12:11, 11 August 2014 (UTC)

There is a way, and it is one I use often: edit, click save, type edit summary, go back, edit... Maybe not the most convenient thing, but it works:Jay8g [V•T•E] 16:02, 11 August 2014 (UTC)
Sorry, that is not useful suggestion and is not a reply to the issue at hand. SpinningSpark 16:20, 11 August 2014 (UTC)
Thanks for filing your idea. I've tried to clarify your request. Whatamidoing (WMF) (talk) 18:25, 11 August 2014 (UTC)

Page options (page settings) menu icon

Tracked in Phabricator
Task T71509

The menu to the left of the “Save page” button is (per the User Guide) the “Page settings” menu (or "Page options", I think I've seen elsewhere). It would be easier to remember what this menu does, and to tell others about it (say, in the User Guide) if the icon for it were the text “Page” (with a down-arrow) rather than three horizontal lines. This menu icon approach is used for the “Insert” and “Cite” menus, which helps users immediately understand (and/or remember) what type of items are on the menu. -- John Broughton (♫♫) 17:22, 10 August 2014 (UTC)

I can make the request, but it may be WONTFIXed. The three-bars icon is used on all pages in Mobile, and I suspect that "consistent interface" is going to be an argument in favor of keeping it. Whatamidoing (WMF) (talk) 00:34, 11 August 2014 (UTC)
Opposed to that, the point can be made that over reliance on icons for communication of functionality has proven to be a bad idea as well. —TheDJ (talk • contribs) 09:47, 12 August 2014 (UTC)

Undo

Undo would be a great feature in VE. I am surprised the developers have not included it. So many applications nowadays have "undo" that it is almost de rigueur. In a long and complex edit, when I have accidentally leant on the keyboard and inserted some random characters in I'm not quite sure where place, I don't really want to discard the whole edit and start over. I just want to undo the last action I did. SpinningSpark 16:45, 11 August 2014 (UTC)

@Spinningspark: Actually, you can "undo" via the toolbar; it's just not as obvious as it might be. Use the icon on the very far left of the toolbar. Also, per the tooltip for that icon, you can also use ctrl(cmd)-Z. -- John Broughton (♫♫) 22:30, 11 August 2014 (UTC)
I discovered this some time ago and was delighted to find it had been implemented. John, since you're doing fairly extensive testing: I have occasionally had bizarre results from the undo function, but haven't been able to reproduce anything reliably. It only seems to happen after a long sequence of complex edits, and if I recall correctly leaves VE hung so I can't save. Mike Christie (talk - contribs - library) 02:20, 12 August 2014 (UTC)
@Mike Christie: Actually, I was just checking how various things are supposed to work, as I was updating the User Guide at MediaWiki, rather than doing extensive testing. The above bug reports are where I encountered something unexpected. Regretfully, I don't plan on doing any comprehensive testing, for the reasons enumerated by PamD: Any bug that isn't causing widespread havoc tends to be taken to be minor by the VE team, so testing work is (at least as I see it) relatively unproductive. -- John Broughton (♫♫) 17:40, 12 August 2014 (UTC)

Category duplication bug (display)

Tracked in Phabricator
Task T70484

Process: For a page with one or more existing categories, open the Category dialog (via the menu to the left of “Save Page”). Then, without doing anything else, click “Cancel”. Reopen the dialog - and every existing category is now listed an additional time. (If you then cancel, then reopen, every category will be listed three times - see screenshot - and so on, as many times as you like.)

I note that this doesn't double (or triple or whatever) categories when saving the page. It's just a display problem - presumably a queue isn't cleared after a click on the "Cancel" button is registered. -- John Broughton (♫♫) 17:09, 10 August 2014 (UTC)

Our QA person found this bug independently (see T70484), and we fixed it about a week ago. If we were on our normal schedule, the fix would have been deployed to English Wikipedia in two days (Thursday the 14th), but because of the deployment freeze during Wikimania everything is delayed by a week, so it'll be deployed the next Thursday. --Catrope (talk) 00:36, 13 August 2014 (UTC)

Unneeded item in page options menu

Tracked in Phabricator
Task T71451

The first item in the Page options menu, “Options”, does EXACTLY what the second item, “Page settings”, does - it opens the dialog box with “Page settings” selected. Can this first, totally extraneous item, be removed from this menu? It just confuses things. -- John Broughton (♫♫) 20:30, 10 August 2014 (UTC)

That sounds sensible. I've filed this in Bugzilla and written a patch. --Catrope (talk) 00:48, 13 August 2014 (UTC)

I'm glad to see that the redlink issue has been fixed, but there are still a number of other issues with links not rendering as seen in view mode. I have consequently reopened bug 38726. SpinningSpark 13:38, 11 August 2014 (UTC)

Thanks for reporting this. I was confused because this has been working for me for a while, but it turns out it was broken in MonoBook because the way it does link styling is slightly different; I didn't notice because I use Vector. I've submitted a patch to MonoBook that makes its link styling also apply to VisualEditor. --Catrope (talk) 01:32, 13 August 2014 (UTC)

Palmares can't be edited in Visual Editor

The {{Palmares}} template (I think it's a template) for sports results (example here - https://en.wikipedia.org/wiki/Li_Jiao_(table_tennis)) cannot be edited in Visual Editor. It's not urgent, but it'd be something that'd probably be a useful function in future. Red Fiona (talk) 23:17, 12 August 2014 (UTC)

This is because the palmares list is between a {{Palmares start}} template and a {{Palmares end}} template. Editing things between start/end templates in general currently doesn't work very well in VE. However, if you double-click the palmares block, you should be able to edit the content in between as wikitext and/or as a series of templates. The same is true for template parameters with rich content (parameters often contain links, for example): you can edit them in VE, but only as wikitext. Some time in the next year or so we hope to be able to provide visual editing of template parameters and content between templates. It's harder than the other template-related things we've done, that's why we did the other things first. --Catrope (talk) 01:57, 13 August 2014 (UTC)

A substituted template?

While stub-sorting, I regularly add the DEFAULTSORT, Category:Living people, and the birth date category or Category:Date of birth missing (living people), just in passing. In the text editor I can do all that in this much typing: {{subst:L|||Waddell, Sarah Jane}} (to quote the example I've just done, Sarah Jane Waddell). In VE ...?

Is there a way to enter a template which has to be substituted, with parameters which don't have field names. I struggled. I gave up. I did it all manually - a DEFAULTSORT and two categories. I then had to fix the "Date of birth missing..." category manually in text editor because I'd mistyped it. Can VE offer any help? PamD 16:47, 12 August 2014 (UTC)

You ideally shouldn't need to correct the spelling of the "Date of birth missing" category because suggestions should be displayed as you type. If that doesn't happen for you, please let us know :) . As for your template adding default sorts, categories, etc., that's a tool that's very much designed and optimized for wikitext users. It doesn't work well in VE because it's not a tool that's designed and optimized for VE users. Such a tool could be created, but it hasn't been yet; VE is relatively new compared to the wikitext editor, so there are fewer community-developed tools for it.
With the new Parsoid API (which VE also uses), though, it should be relatively simple to write a Gadget that adds this information without even leaving the page or opening an editor. Some people are already writing Gadgets using this API, like WP:EPH. You may be able to find someone willing to write some tools to do simple BLP gnoming tasks in VE or even straight from the page using the Parsoid API.
BTW, the way you do unnamed parameters in VE is by calling them "1", "2", "3", etc. So what you're trying to do may be possible by trying to insert a template called "subst:L" and adding a parameter named "3" with the value "Waddell, Sarah Jane". --Catrope (talk) 02:11, 13 August 2014 (UTC)

Stop the animation please

Can we please have the "pop-up dialogs" (eg when you click "Save page") just appear and disappear without the animations (ie expanding and shrinking). The animations are annoying and don't add any value. Mitch Ames (talk) 06:45, 9 August 2014 (UTC)

I'll pass along your feedback the next time I talk to the product manager. If anyone else has an opinion on this, please feel free to add your views here, too. Whatamidoing (WMF) (talk) 06:10, 10 August 2014 (UTC)
Are per-user options feasible? I'd be the first to admit that my personal preferences may not match other'. Mitch Ames (talk) 08:28, 10 August 2014 (UTC)
Wondering if it might be possible to disable this with you user css or javascript. Some animations are done using CSS transitions, if VE is using this then is finding the right css selector an a one line bit of custom css could do the trick. --Salix alba (talk): 09:17, 10 August 2014 (UTC)
I'll ask around and see what information I can turn up. It may take a while. Whatamidoing (WMF) (talk) 00:30, 11 August 2014 (UTC)
I don't think personal css is a good solution, more ccs/js bloat. It should be a simple setting in preferences. SpinningSpark 11:16, 11 August 2014 (UTC)
I strongly doubt that we'll convince the devs to accept yet another user pref for something that so few people seem to care about. They've spent the last couple of years weeding out prefs and skins that are used by very few active editors. Whatamidoing (WMF) (talk) 17:46, 11 August 2014 (UTC)
The following CSS eliminates the opening/closing animations (all animations in fact) on all dialogs: 
.oo-ui-window, .oo-ui-window-frame { transition: none !important; }
--Catrope (talk) 00:25, 13 August 2014 (UTC)
Actually, I find the animation annoying too, and it doesn't appear to have any functional purpose. Remember that every little frill you add has a genuine performance cost; it's bad enough here, please think of the global south editors who are having a hard enough time just getting the pages to load. Risker (talk) 00:44, 13 August 2014 (UTC)
CSS3 animations do not affect performance. They instruct the browser to gradually transition (note that the CSS I wrote uses "transition", not "animation") from one state to another over a specified period of time. For the dialog opening transition, that's 250ms (a quarter of a second). The duration is fixed, the gradual-ness is best-effort. If you have a slow browser, you shouldn't see a slow-motion transition lasting multiple seconds, you should see a jerky transition that completes in the same amount of time, or no transition at all. The slow-motion behavior is what you'd see if we'd used JS animations instead; which is exactly why shy away from JS animations, use CSS3 transitions wherever possible, and avoid doing things that are not possible with CSS3 transitions. As far as performance goes, we're already in excellent shape on the animations/transitions front and we have much bigger fish to fry elsewhere.
What does bother me is that there is currently a delay between clicking a button and the start of the opening transition. This is because we do work during that time, but 1) there's no indication to the user that their click registered and we're doing work, and 2) during the opening transition would be a great time to do work like that. I think we have a bug filed for this somewhere, but it's not very easy to fix, because it's possible that the work might take longer than the transition, so we need to come up with a way to handle that case. --Catrope (talk) 01:08, 13 August 2014 (UTC)
Thanks for the details, Catrope. However, even if it costs not a single iota of performance(and yeah, all those 250ms things add up), it's still annoying. Flashiness is not needed, it doesn't add anything to the functionality, it just makes it look more game-like. To me, that's a net negative. Risker (talk) 03:57, 13 August 2014 (UTC)
James F tells me that there's strong evidence (in human–computer interaction research) that animations reduce the cognitive burden. If you don't like it (I wouldn't like it if it were jerky, but I hadn't paid any attention to it before it was mentioned), then feel free to disable it in your .css file. Whatamidoing (WMF) (talk) 17:07, 13 August 2014 (UTC)

Default edit summary

Tracked in Phabricator
Task T71501

It's not possible to select a section of an article to work on, so how does the Visual Editor decide what the default edit summary ought to be, as in "/* Themes */ " for instance? That's a real-life example where I'd actually edited several sections, as the entire article was in front of me. Eric Corbett 21:02, 9 August 2014 (UTC)

I believe what it does is take the name of the section you clicked on to edit, even though it will always allow you to edit the entire article. Mike Christie (talk - contribs - library) 01:17, 10 August 2014 (UTC)
Seems to me to be almost entirely random, but either way it's not much good then, suggesting as it does that I've only edited one section. Eric Corbett 01:31, 10 August 2014 (UTC)
Someone who can remember more accurately than I do will no doubt comment, but I believe this feature was added on request -- some editors wanted a default message to indicate in the edit summary which section they'd been editing. I don't think this is useful and I think it should eventually be removed, unless some way is implemented to edit only a single section, which is not currently high on the list of requests. Mike Christie (talk - contribs - library) 01:38, 10 August 2014 (UTC)
Yes, it was added last year at the request of English Wikipedians.
Eventually, the team hopes to add an actual edit summary based on the changes you made. This will probably work better for small changes ("teh → the") than for wide-ranging ones, but it should at least be able to figure out that you've made changes in multiple sections, and then remove the inappropriate section label (or, alternatively, to figure out that your changes were all within one section, even though you clicked the button at the top of the page, and thus offer that section name as a default). I don't expect to see any of this during this year, however. Whatamidoing (WMF) (talk) 06:08, 10 August 2014 (UTC)
Adding the section name is a useful feature. If one clicks on a section edit link it is a fair assumption that the intention is to edit that section. It can easily be backspaced over if that was not the intention or one subsequently decides to edit more sections. The other way around, if the section was not automatically added, it is quite problematic to add it manually so what we have now is the best solution. SpinningSpark 11:36, 11 August 2014 (UTC)
That's not true. I just edited this article by clicking on the edit beta button in the lead, but the edit summary that came up was "References", which I never touched. Added to which after I'd saved the page the edit buttons allowing me to edit the lead disappeared until I reloaded the page. Hardly a show stopper I agree, but one more drip, drip in the bugs that don't seem to get fixed in a timely manner. Is there actually any point in making further bug reports? Eric Corbett 18:28, 11 August 2014 (UTC)
Eric is correct; I just reproduced this. I'd forgotten that there's a gadget you can turn on that adds "edit" links in the lead; they're not there by default. I don't have them turned on normally, but I realized that's what must be happening when Eric said "the edit beta button in the lead". Clicking that button leads to an edit summary which appears to be taken from the next section. I would think this is an easy fix -- section 0 editing should simply drop the summary. Mike Christie (talk - contribs - library) 18:47, 11 August 2014 (UTC)
You're right Mike, it does seem to be picking up the following section name rather than being random as it initially appeared to me. There's another related problem though, which is that after editing this article for instance both of the edit buttons disappear from the lead, replaced by a small version of the article title until the page is reloaded. Eric Corbett 19:27, 11 August 2014 (UTC)
Hmm. I can't reproduce this. I'm using Chrome on Windows 7; what OS and browser are you seeing this with? Mike Christie (talk - contribs - library) 02:10, 12 August 2014 (UTC)
I'm using Firefox 31.0 running under Ubuntu 12.04. The same thing happens when I use Chrome, version 36.0.1985.125. Eric Corbett 14:56, 12 August 2014 (UTC)
I'll file the bug report, but I expect it to be closed as "local gadgets are somebody else's problem". Whatamidoing (WMF) (talk) 17:09, 13 August 2014 (UTC)

Dialog box still hides content

Tracked in Phabricator
Task T51969

(I followed a link to leave feedback but then realised I'd done so at [[2]], so am copying it here too). In response to the pleas just published I thought I'd give VE another shot, having trialled it a lot in earlier days and given up in sheer exasperation at its inadequacy. Sadly, there's no progress on one of my main complaints, probably my major problem with VE: the dialog box hides the content of the article. So if I'm adding a categoroy or a stub template I need to have memorised all the relevant details from the article before calling up the dialog box. I can't shift the box, or shrink it, so that I can read the article: it just hides it. I might persevere for a while, as the developers seem desperate for feedback, but for me this is the killer problem: it's just not fit for purpose. PamD 21:31, 10 August 2014 (UTC)

Yes, there has sadly been no real progress on T51969. The entire windowing system was re-written, and so now I believe that it's finally possible to fix this. But I don't know when it will happen: it's not on the schedule yet. Whatamidoing (WMF) (talk) 00:38, 11 August 2014 (UTC)
I know Pam is on the bug cc list, but for those who aren't, I'll note here that I just posted a comment at bugzilla that this issue seems to belong to the UX Design group, not the VE team, because the windowing system used by VE is from the OOjs UI, which is managed by the Design group. (The windowing system currently lacks the ability for the user to move or resize a dialog window.) -- John Broughton (♫♫) 17:06, 11 August 2014 (UTC)
I see that James Forrester just added a comment to that bug to the effect that this is not high priority, because it's not as important as "editing tables, editing in Chinese, or editing galleries. It strikes me that this is at least as important as editing tables, and definitely higher priority than editing galleries, as it comes up much more often. As for editing in Chinese, I think you can make the case that this bug is more important -- it's important to get VE in heavy use by at least one user community, which it currently is not, and going for broad functionality rather cleaning up all the things that prevent productive editors from using VE is not necessarily the right approach (though I can see both sides for that one).
Is there a way for users to "vote" for bugs, as the Firefox development team's bugzilla configuration allows? That would allow the developers to get a more quantified sense of what bugs are causing people not to use VE. Mike Christie (talk - contribs - library) 17:18, 11 August 2014 (UTC)
Voting is turned off on Bugzilla for VisualEditor. Voting is ignored on Bugzilla even if it's been turned on for a product.
At some projects, VisualEditor is being used by half of IPs and almost a quarter of registered editors. It's not used for most edits, but that's significantly due to overcounting of "wikitext" edits. The two categories in the stats are "VisualEditor" and "other", where "other" includes every use of WP:UNDO, WP:ROLLBACK, WP:AWB, WP:TWINKLE, WP:HUGGLE, WP:SNUGGLE, and any other script using the API, not just edits in which someone actually typed in the wikitext window. It might be interesting to get more precise numbers, but no one in the analytics department is assigned to VisualEditor. Whatamidoing (WMF) (talk) 18:10, 11 August 2014 (UTC)
I don't know why voting is turned off, but I would like to see some method for the editing community to express their input in a quantitative way. I'm not just talking about en-wiki. I believe the dev team is doing a pretty good job at figuring out what editors want and need, but part of developing a relationship with one's customers is having two-way communication that means something. Addressing bugs that are annoying a lot of users is (a) worth doing as part of engaging those users, even if you're not convinced they're right about the priorities, and (b) hard to do if you don't know exactly how many users care about each bug. I think the relationship between the devs and editors would improve if there were a way for editors to see that their input made a real difference to prioritization. Mike Christie (talk - contribs - library) 02:18, 12 August 2014 (UTC)
I'm in favor of that. The problem with voting is that it is only 1 metric and people tend to get hung up on it. "This is popular you should thus do it", which does not take into account things like complexity, impact and alternative ideas/implementations. Since those simply are almost always more important, developers tend to fully ignore votes, because desirability is often already understood from context, comments and on wiki situation. I agree with your principle that something is needed, but it is difficult to identify what that solution should be. You also don't want to spend too much time on it for ALL bugs, because the majority of them simply never have such an interaction anyway. Anyway, in the future we will have phabricator and that might allow is to be a bit more flexible on reporting fronts. —TheDJ (talk • contribs) 09:45, 12 August 2014 (UTC)
"Voting" has the potential to make the community feel overlooked: "A bunch of us voted for this, and you still haven't fixed it!" But something like "I have this problem, too" might be a useful way to keep track of how prevalent a problem the bug is, without creating a false expectation that the users (who, as TheDJ points out, have important but very narrow view of the situation) are making decisions.
I wouldn't want to start anything now, though, because Bugzilla requires publishing your e-mail address to the world. Phabricator is supposed to be connected to SUL, so your Wikipedia username and password will get you in. Whatamidoing (WMF) (talk) 17:20, 13 August 2014 (UTC)

Removing tag within "multiple issues"

OK, I'm trying to use VE. Wanted to remove an irrelevant tag from within {{multiple issues}} in Personal guarantee. Hovered over the area, it went blue. Double-clicked: it showed me the contents of the MI template in a dialog box ... but then dropped me out of VE into the old editor. Am I missing something? Is it impossible to edit the tags within {{mi}}, or just non-intuitive? I removed the tag old-style having been defeated by VE. PamD 13:19, 12 August 2014 (UTC)

When you say "dropped me out of VE", do you mean it completely switched to the wikitext editor? What I get when I double-click the template is the template interface, with the wikicode showing as a parameter: {{unreferenced|date=August 2014}}{{copy edit|date=August 2014}}. These can just be edited as wikitext at this point; I don't think VE can yet provide the template editing interface for nested templates. Is this not what happened when you tried it? Mike Christie (talk - contribs - library) 13:32, 12 August 2014 (UTC)
Yes, it switched me right out into the wikitext editor. But I can now see that I should have: hovered to make it blue, then clicked once to make it darker blue, then clicked once on the little box below with jigsaw piece and template name "multiple issues". This then gives me a dialog box (the one I used to see fleetingly before it disappeared, by erroneously double-clicking!), where the list of templates/tags within {{mi}} appears in a parameter box under "Issues" and can be edited to remove or add tags. So just non-intuitive, rather than impossible, of my two options above. But I'm coming back to VE as someone who hasn't used it for many months, so still clambering up a steep (re-)learning curve. Not sure how my experience compares to a genuine new editor - but genuine new editors come from such a huge range of prior experience that what's natural and intuitive to one will be totally obscure to another. PamD 14:24, 12 August 2014 (UTC)
Actually, I think double-clicking should have worked -- it does for me. What browser and OS are you using? Mike Christie (talk - contribs - library) 15:14, 12 August 2014 (UTC)
Firefox 31.0 and Windows Vista 6.0. PamD 15:57, 12 August 2014 (UTC)
PamD, I can't reproduce this on my Mac.
Do you have the "Edit pages on double-click" enabled in Special:Preferences#mw-prefsection-editing? Whatamidoing (WMF) (talk) 17:30, 13 August 2014 (UTC)

Annotation to ref didn't show up within VE

In editing Nimitala I added a "clarify" template within a reference. It looked OK within the dialog box, but didn't show up when I returned to looking at the whole article in VE. But when I saved it and left VE, it has appeared OK (the little superscript "Clarification needed"). This should have appeared while I was still in VE: if I make a change which ought to have a visible effect, and it doesn't appear to do so, I don't know if my change has worked and I shouldn't have to save the edit before I can find out. PamD 14:02, 12 August 2014 (UTC)

The contents of {{reflist}} don't get updated. This is a case of "can't", not "won't". If the page used the core MediaWiki code rather than the en.wp-specific template, then you would have seen it updated immediately. (Also, <references /> is slightly faster and the template is kind of pointless when you're not using any of its features. The output is exactly the same.) Whatamidoing (WMF) (talk) 17:34, 13 August 2014 (UTC)

"Get me out of here"

I looked at an article, opened it in VE (to answer a question above), didn't want to make any edits ... and couldn't find an "Exit". "Save" wasn't highlighted ready to click as I hadn't made any changes. Yes, I could have just closed the tab - but I might have wanted to carry on reading the article, or to come back to editing it after a Real Life interruption(phone ringing, dinner to get out of oven, ...). I looked at various menus, options, etc but couldn't see a way out. Am I missing something? (In which case I suggest that many other editors might miss it too). The place I expected to find it, given that it wasn't visible, was within the menu revealed by clicking the "menu" button to the left of the "Save" button - this includes the option to switch to text editor, but not "Exit without making changes" which I was wanting). PamD 14:30, 12 August 2014 (UTC)

I agree, this is very confusing for a new user. There used to be a Cancel button, but above you'll see that the developers found very few people actually used it, so they removed it. There is a short cut key to flip to the Article tab: Alt-Shift-C on PCs; Ctrl+⌥ Option+c on Macs. That short cut eliminates the need for the cancel button as far as I'm concerned but I don't see how any user would ever figure that out. Mike Christie (talk - contribs - library) 15:13, 12 August 2014 (UTC)
You can also click the "Read" tab to switch back to read mode (and unlike in the wikitext editor, this doesn't reload the page, so it's quick); you clicked the "Edit" tab to switch from reading to editing in the first place, so this mirrors that. If you click "Read" when you have unsaved changes, you will first get a warning that you're about to discard those changes; but the Cancel button did that too.
That's simply ridiculous. Have you ever seen any other WYSIWYG editor work in that way? Eric Corbett 01:59, 13 August 2014 (UTC)
I don't know why it works that way, I'm just telling you that it does :) . I don't think I'm the best person to comment on user interface design (I'm an engineer, I can tell you exactly what I built, but not always precisely why I was asked to build it), but I'll remark that most other editor software I've used doesn't have a read vs edit distinction, nor a cancel button; instead, there's only an edit view, and to "cancel" you close the editor. Wiki pages are a bit different that way: there aren't a lot of things out there that try to give you a smooth switch between a reading experience and an editing experience, because there aren't a lot of places where the distinction between readers and editors is intentionally blurred. Maybe there should be another way to exit (there used to be a "Cancel" button next to the save button, but it was removed recently because it was rarely used and occupied prime real estate), I don't know, but I'm not sure it's easy to draw parallels to other editors here. --Catrope (talk) 02:56, 13 August 2014 (UTC)
Yes, other editors appear to work that way. I just checked Google docs, and I found no 'Cancel' button there. Whatamidoing (WMF) (talk) 17:37, 13 August 2014 (UTC)
In the same spirit, clicking the "Edit source" tab now asks you if you would like to switch to the source editor with the changes you made in VE already applied. Previously it would just discard your changes and have you start from scratch in the source editor; that's still an option we offer in case you did want to start over. Right now you can't switch from the source editor back to VE while preserving your changes, which is why we warn you before switching to the source editor. In the future, you'll be able to switch in both directions. --Catrope (talk) 01:42, 13 August 2014 (UTC)
How far in the future? Eric Corbett 01:59, 13 August 2014 (UTC)
I thought this was listed in our annual goals but apparently it's not. It may or may not be scheduled for some point in time, but I can't find that information right now. This feature depends on some Parsoid work and will probably be combined with some design work (like merging the VE and source edit tabs, and pushing that distinction into the edit page instead). I'd really like to see it happen this fiscal year (2014-15) but I'm not someone who decides/schedules such things, I write code instead :) --Catrope (talk) 02:22, 13 August 2014 (UTC)
I believe that it's not on the schedule yet. Whatamidoing (WMF) (talk) 17:37, 13 August 2014 (UTC)

Wikilinking within a reference

In my creation of Alf Cooke printworks I added references. For one of them, I wanted to link to the newspaper title. Sure enough, the "Info" button for the "Work" field of "Cite newspaper" tells me "Name of the source periodical; may be wikilinked ...". But how do I wikilink it? I highlighted it and looked around for a clickable link icon - nothing to see. Just as a very long shot, I tried adding our oldfashioned square brackets: "[[Yorkshire Evening Post]]". It worked. How do we expect new editors, who're supposed to be using this super-user-friendly interface, to know how to do that? PamD 16:22, 13 August 2014 (UTC)

Right now, we don't. But those will eventually become rich-text interfaces, and the links will work like any other link in the article text. Whatamidoing (WMF) (talk) 17:54, 13 August 2014 (UTC)
Tracked in Phabricator
Task T54462
Tracked in Phabricator
Task T71359
Tracked in Phabricator
Task T71500

(Note: As I've been updating the VE User Guide, at MediaWiki, I've noticed a bunch of non-major issues. I'm posting these separately, mostly, to make it easier to discuss each separately.)

(1) If you click on the link icon on the VE toolbar by mistake, you’re looking at three choices: “Done”, “Remove”, and “Open”. There is no obvious way to correct your mistake. It would be nice to have a “Cancel” button as well.

(2) Also, it would be ideal, in the Link dialog, if non-available choices were greyed out. For example, if no text is selected before the dialog begins, then at least the “Remove” and “Open” buttons should not be user-clickable. (If clicked in this situation, the “Remove” button closes the dialog; I’m not sure that makes sense.)

(3) Finally, if a person begins text entry with “http”, then VE should automatically turn off the “assist” function, which is designed to help with internal links, but is pointless for external ones. (VE knows, when the dialog is done, to save the link as external one, not an internal one; if it knows that upon saving, it should also be smart enough to know it when data entry is going on.) -- John Broughton (♫♫) 19:56, 7 August 2014 (UTC)

On #3, how would you link to http:// (a redirect)? Whatamidoing (WMF) (talk) 19:24, 8 August 2014 (UTC)
Well, wiki syntax does not allow the internal link [[http://]], instead rendering [[http://]]. There's no real point in linking to pages beginning with URL protocols, and the MediaWiki software really ought to disallow the creation of these pages at a low level (similarly to how the page "~~~~" cannot be created). Agree with #2 though. — This, that and the other (talk) 10:31, 9 August 2014 (UTC)
On #3, I'd rather make contributors use the wikitext editor for those exceedingly rare situations for links to an internal page that begins "http", than keep in place an almost totally useless "assist" function because of the less-than-one-in-a-million probability that it might be useful. Besides which, typing "htt" [at which point the assist function is still working] provides the opportunity to click on the page named "http://", and thus to select such an internal page before the assist function gets turned off. -- John Broughton (♫♫) 20:24, 9 August 2014 (UTC)
Bug 52462 now has a comment about #1. It may need to be a separate bug report, if they're still maintaining the previous distinction between "dialogs" and "inspectors".
Bug 69359 is about #2.
For #3, do we want two bug reports? On the one, we could recommend disabling the search, and on the other, we could recommend disallowing these as page names. Whatamidoing (WMF) (talk) 06:29, 10 August 2014 (UTC)
Thanks for the bug reports. For #3, just one bug report, thanks. I'd like to avoid arguments about disallowing pages, so I vote for door #1 - Disable the search at the point where the user has typed "htt" [or, if that would affect processing effort or speed too much, then perhaps check each character as it is typed; if the user types "/" [very rare], then check if the first three characters are "htt"; if so, then disable search. -- John Broughton (♫♫) 16:44, 10 August 2014 (UTC)
This is now T71500 Whatamidoing (WMF) (talk) 22:22, 13 August 2014 (UTC)
And add for #1 that the Esc key is behaving in a totally unexpected way (the link is created...). I tried to explain that in bugzilla 68101 but the only answer I get from James is that it's normal that Esc key doesn't cancel... --NicoV (Talk on frwiki) 19:07, 10 August 2014 (UTC)
I agree. WONTFIX for this bug means WONTINSTALL on en.Wikipedia. "Escape" is "do not save" (and sometimes close without saving) in all programs I'm familiar with. It is never "close and save". A marginally acceptable alternative is to have a [CANCEL] button in fixed absolute and fixed relative positions. This is, IMO, one of the few showstoppers. — Arthur Rubin (talk) 16:06, 11 August 2014 (UTC)
Tracked in Phabricator
Task T71506
Tracked in Phabricator
Task T71507

Categories assigned to a page are only visible, when in VE edit mode, via the Categories dialog (from the Page options menu). That’s not consistent with the VE approach of showing editors, during the edit, what the page will look like to readers. And it’s specifically a problem when a category assigned to an article has no corresponding category page. In that situation, the category link on the article page is red. But this type of redlink isn’t identifiable as such in the categories dialog box (both bluelink and redlink categories are shown identically).

Example where this is an issue: You start editing a problematical article. If there is a redlink category, you’d probably delete it - at least you’d give that serious consideration. But in VE, you don’t know that any categories are redlinks unless you made a note of that before you started editing.

So, a recommendation: In VE, display the categories at the bottom of the editing page, just as the wikitext editor does when previewing a page. If the user clicks on one of those categories, do something similar to what happens when someone clicks on a citation in the References section - either display an icon that, if clicked, opens a dialog (in this case, the Categories dialog), or just put him/her directly into the dialog. -- John Broughton (♫♫) 17:02, 10 August 2014 (UTC)

Two bugs: show me the cats, and show which are red. Whatamidoing (WMF) (talk) 23:14, 13 August 2014 (UTC)

Problem with inserting a special character

Note: As mentioned previously, I'm posting quite a bit because of my work with the VE User Guide. The nine suggested improvements, above, and this and the six more to follow, are admittedly not deal-breakers. But I hope the (relatively) minor nature of them won't cause them to be moved to the bottom of a large queue, because (a) almost all of them can be fixed with relatively little programming, I believe, and (b) taken as a group, these 16 bugs significantly (in my opinion) raise the level of annoyance with VE - it generally works well, but there are still lots of things that can be seen - falsely or not - as a disregard of what new editors need, which is obvious ways to do things and very few flaws.

After inserting a special character (Insert menu, click on a special character), the page is automatically scrolled down by VE so that the insertion point is no longer visible on the page. That's confusing (and unnecessary). -- John Broughton (♫♫) 20:29, 10 August 2014 (UTC)

I reproduced this once in Safari, and now I can't. I haven't managed to reproduce this in Firefox. Can you get this to happen twice in a row?
I wonder if it's due to the size of the special characters dialog here at the English Wikipedia. It would be interesting to know if it happens at other places, too. Whatamidoing (WMF) (talk) 23:40, 13 August 2014 (UTC)
Tracked in Phabricator
Task T71510

In the Media dialog [digression: why does the window for the dialog have the label "Media settings" rather than just "Media", and are the two Media dialogs shown in the User Guide, one to select an image, one to deal with captions and similar, the same dialog or two separate ones?], once an image has been selected, the user can add a caption, and can make some or all of the caption into a link.

Issue: If you select some text (say, "George Washington"), then click on the link icon, the link dialog appears. But the dialog won't show matching (internal) pages for the selected text until you click in the link dialog text box. That’s an extra, unnecessary click; more importantly, users may not be aware that this is even an option, and just click “Done”. This is a bug: the matching process should be in effect immediately.

(Technical note: this appears to be a focus issue. If you switch to another application, then back to the web browser page where you're doing VE editing, the focus does move to the text box, and that in turn means that matching pages are shown. So it looks like what needs to be done is to fix the focus at the point where the user has clicked on the link icon.) -- John Broughton (♫♫) 20:49, 10 August 2014 (UTC)

Also, I've got a problem with the link tool's box being too small. I'll file that one separately in a few minutes. Whatamidoing (WMF) (talk) 23:50, 13 August 2014 (UTC)

Excess tabbing through Cite mini-editors

Tracked in Phabricator
Task T71512

This is what tabbing through Cite templates (in the mini-editors) looks like: type, tab, tab, tab, type, tab, tab, tab, type, ... You have to tab three times to get from one field to the next. That's because tabbing always includes both the “Field description” and “Remove field” icons. There isn't any reason to include these icons in tabbing; tabbing should bypass these icons.

(Technical note: I'm guessing that this is caused by the tab positions (numbers), which determines the tab sequence, that are assigned to the field descriptions and remove field icons. So the tab numbers should be removed for these icons. Or, if the icons absolutely must have tab positions, those positions should place the icons at the very end of the sequence.) -- John Broughton (♫♫) 03:59, 11 August 2014 (UTC)

This is to enable keyboard navigation. The confusion probably stems from the fact that some browsers don't have keyboard navigation enabled on buttons by default, and this are not actually buttons, so the browser is not able to make that distinction. I'll see if this can be improved. —TheDJ (talk • contribs) 09:34, 12 August 2014 (UTC)
I agree. On the one hand, I like everything to be accessible from the keyboard. On the other hand, I would really like to tab between parameter fields, not tab-tab-tab between them. Whatamidoing (WMF) (talk) 23:58, 13 August 2014 (UTC)
Tracked in Phabricator
Task T55973

Trying to edit the name of a link often results in the phrase being delinked altogether. It's fine if the edit is in the middle of the link text, but if the whole text is selected the new text appears as just plain text. This is not reliably repeatable. It happens most of the time, but not always and I can't figure out what the difference is. It might be something to do with whether the link is piped or not at the start of the edit. SpinningSpark 14:02, 11 August 2014 (UTC)

A related problem is that appending text to the end of the link works until a space is typed. The space and anything after it become plain text. SpinningSpark 10:28, 12 August 2014 (UTC)
@Spinningspark: The solution is to start editing from somewhere in the middle of a link label. First add all the text you want, then delete text at the beginning and/or end to get the label to read exactly as you want it.
More generally, this is another example of why the link dialog, as discussed in the section immediately above, should show two fields: (1) the url or wikilink, and (2) the label. That way, people who can't figure out the tricks of editing the label on the main VE page would have an alternative. -- John Broughton (♫♫) 00:10, 14 August 2014 (UTC)
Thanks John, but I already realised I can work around it. It does not stop it being a problem that should be fixed. SpinningSpark 00:14, 14 August 2014 (UTC)

if gte mso 9... Nonsense inserted by VE

Tracked in Phabricator
Task T71513

Hi, since yesterday I came across at least 2 articles where VE injected nonsense. I didn't note which was the first article, thinking it was an isolated thing, but here's the second problem. Please fix. --NicoV (Talk on frwiki) 09:38, 11 August 2014 (UTC)

Other examples from this list: Paul Cère, Paul Cère, André Grassi, Capitulaire de Coulaines, Charles Ateba Eyene, ... The first example I found is Catherine Lemorton, on August 1st. --NicoV (Talk on frwiki) 09:43, 11 August 2014 (UTC)
Thanks, NicoV. This is a new case of garbage being injected to track under T54327. I'll get you a bug number. Whatamidoing (WMF) (talk) 18:22, 11 August 2014 (UTC)
User:NicoV, this new editor is the only one in the list that has an account registered. Do you think it would be useful for you or User:Elitre (WMF) to try to find out what his computer setup is like? Whatamidoing (WMF) (talk) 00:09, 14 August 2014 (UTC)
I posted a question on this user talk page. --NicoV (Talk on frwiki) 07:03, 14 August 2014 (UTC)

Tags: nowiki added, VisualEditor in contribution

Hi,

I am testing VE since a few days now. Some of my recent contributions display the following tags: nowiki added, VisualEditor. I have realized that the tag "nowiki added" is added every time I have used the option Cite Journal of VE in the content. Have you noticed some errors / bugs as for inline cite is concerned or am I not using the tool appropriately? Are the contributions taken into considerations despite the presence of the "nowiki added" tag or shall I re-edit once? Thank you — Preceding unsigned comment added by BioFilip (talk • contribs) 15:37, 13 August 2014 (UTC)

It looks like for your first "nowiki" edit, you tried to make a wikilink for immunogenicity by typing [[immunogenicity]]. Unfortunately, the double-bracket notation doesn't work in Visual Editor, and the VE team says they're not going to fix that, despite quite a few of us asking them to. Instead, VE just wraps <nowiki> tags around the link you tried to make, leaving it for the next editor to clean up. Fortunately, the next editor was you, so the link is now as you intended.
In your second "nowiki" edit, you added a reference with the journal name "BONEKEY REPORTS | REVIEW". That pipe ("|") is a special character that VE needs to wrap <nowiki>s around; that's not a bug, nor anything you did wrong, that just an artifact of the way wikitext is stored.
In both cases your edits went through fine eventually, so you don't need to re-add anything. (But you can certainly double-check and look over the article to make sure that everything you intended to add did make it through.) 28bytes (talk) 16:08, 13 August 2014 (UTC)
In the second case an arguably preferably behaviour would be to use the {{!}} magic word which is specifically designed for use in template. This recently was promoted from a template Template:! to a magic word so should work on all wikis. I've started T71482 for this.--Salix alba (talk): 17:01, 13 August 2014 (UTC)
Thank you for your input. I will check the pages. by BioFilip : 07:1, 14 August 2014 (UTC) — Preceding undated comment added 07:44, 14 August 2014 (UTC)

Images - can't add?

I bravely tried to use VE to create a new article from scratch, Alf Cooke printworks. I wanted to add an image, found a nice one in Commons, found a button saying "Insert Media", got a box labelled "Media settings" with one input box, added the file name ... and nothing happened. Tried removing "File:", still no joy. Couldn't see any way to do anything useful. Gave up (at least there was a "Cancel" button, be thankful for small mercies). I added the image later in text editor, where I found a button I'd never noticed before which made it an absolute doddle, even easier than the simple line of typing I was going to do.

Am I missing something about how to add an image? PamD 16:15, 13 August 2014 (UTC)

VisualEditor shows you whatever Search finds. (Calling Chad!)
In this case, if you search for File:Alf Cooke's Packaging, then you find it. If you search for File:Alf Cooke's P, then you don't. You get the same results in VisualEditor that you would get if you were searching on Commons itself. Whatamidoing (WMF) (talk) 17:53, 13 August 2014 (UTC)
More to the point, if I search on File:Alf Cooke's Packaging Factory - Hunslet Road - geograph.org.uk - 483165.jpg (copied from the heading of the page at https://commons.wikimedia.org/wiki/File:Alf_Cooke%27s_Packaging_Factory_-_Hunslet_Road_-_geograph.org.uk_-_483165.jpg), then I don't find it. If I search on File:Alf_Cooke's_Packaging_Factory_-_Hunslet_Road_-_geograph.org.uk_-_483165.jpg (copied from the URL of that page, with underscores for spaces), then I find it. If I search on File:Alf_Cooke%27s_Packaging_Factory_-_Hunslet_Road_-_geograph.org.uk_-_483165.jpg (I'm now so confused that I can't remember where I got that version from, with underscores and the "%27" for apostrophe ...) then it doesn't find it. Most places in WP underscores and spaces are interchangeable - but not in this particular search. Not a happy experience.
Thanks for the explanation, anyway. Another aspect of VE to not bother trying to use again. PamD 19:42, 13 August 2014 (UTC)
And ping NEverett. Was also reported earlier on Search feedback page. —TheDJ (talk • contribs) 09:57, 14 August 2014 (UTC)

Just wondering

I am curious, why is it necessary to press an edit button at all, in VE? Wouldn't it be more practical, and inviting, for the editing ability to be ever-present, and the focus of VE editing to center on saving the changes when ready to publish? Even dimming the page slightly defies WYSIWYG for that matter. In my crude opinion. Cheers.—John Cline (talk) 06:46, 10 August 2014 (UTC)

@John Cline: If I understand you correctly, you're saying that every time a reader opens a Wikipedia page, the system should process that page so it is ready for editing. The problem is that those who read a page outnumber those who edit a page by at least 1000 to 1, so in all but a very small percent of the time, this processing (Parsoid) would be wasted. And that processing is not trivial - one of the known problems with VE is that it's slow to open longer articles because of the processing required.
I think there is a long-term plan to change the format in which pages are stored, so they are much quicker to display for editing, but still, as long as there is any significant time/effort required to make pages ready to edit, the overwhelming ratio of reader to editor argues against non-instantaneous editing. -- John Broughton (♫♫) 16:51, 10 August 2014 (UTC)
Thank you for that reply. I understand your clear answer, and am drawn by its logic to agreement.—John Cline (talk) 18:00, 10 August 2014 (UTC)
I'd never thought about this before. I'd be worried about random key presses (are any of you owned by a cat?) making unwanted changes to articles. I suppose you'd still have to save, but any change would presumably cause the warning about leaving the page with unsaved changes, and I think we might end up with a lot of accidental vandalism that way. Whatamidoing (WMF) (talk) 00:28, 11 August 2014 (UTC)
With increasing use of mobile /touchscreen devices it would be a nightmare! As it is, I regularly accidentally "Thank" editors while looking at watchlisted changes because the "thank" button is too near my phone's "back" button.05:11, 11 August 2014 (UTC)
I can certainly appreciate that reasons exist to forgo such an approach. At present, the unintentional saving of unwanted changes is not one that I fear would ubiquitously occur. Especially when it seems that saving a change requires redundant affirmation. Even thanking an editor requires a confirmation of intent. Furthermore, every word processing program I've ever used is active in edit mode upon opening the page; warning the user when they exit a page with unsaved changes. Presuming most users don't begin using computers and Wikipedia in concert, they would have experienced such active editing and warnings of unsaved changes before ever opening a Wikipedia page. By that matrix, opening a page and not being able to edit would belie the norm they had otherwise come to know. These are the thoughts which underpinned my curiosity, and my question. Thank you for giving it fair consideration.—John Cline (talk) 08:49, 11 August 2014 (UTC)
Tracked in Phabricator
Task T63737
Couple of comments:
  1. No, "thanking" in mobile Wikipedia mode doesn't require any confirmation: one accidental click while dropping the phone, and you've thanked someone irreversibly. A piee of very bad interface design, to my mind!
  2. Reading (as opposed to choosing to edit) a WP article isn't like using a word processor, it's more like reading an online newspaper or other website: you don't expect that every touch on the screen/keyboard will make a change to what you're reading. PamD 10:00, 11 August 2014 (UTC)
Yes, I had considered some of these things as well, and do not disagree. Mine was more from a curious notion; not advocating it at all. And I managed to learn a few things. For me, that counts as a good day. Cheers.—John Cline (talk) 13:09, 11 August 2014 (UTC)
Quiddity, do you think that you and User:Maryana (WMF) or User:Deskana could figure out what's going on with the zero-confirmation thanking on mobile? This was a real problem on desktop in the early days, and I'm not keen to see it continue on Mobile. User:PamD, we'll need to know whether you're using mobile web (in your device's normal browser) or the specialized mobile app. Whatamidoing (WMF) (talk) 18:05, 11 August 2014 (UTC)
I second that. This same complaint about unintended accidental thanks on mobile was repeatedly voiced on german WP as well. It is also bad to have different UI behavior for the same feature on mobile than desktop. BTW, i really hate that the WMF mobile team is not able or not interested in providing feedback channels for their "features", design decisions, betas, bugs etc. After something like 2 years they have recently filed one bug for this T67078 (Allow feedback for mobile beta features like Desktop) and that's it, nothing is happening. --Atlasowa (talk) 20:29, 11 August 2014 (UTC)
@Whatamidoing (WMF): To be honest I'm not sure whether it's the app or browser! I guess the latter - I click on "Internet" and then one of several bookmarked pages for my Watchlist, Category:Stubs or WP home page.A "menu" icon gets me "settings" where I have selected "images on", "beta on" "experimental mode off". I'm using an Android phone, Samsung Galaxy Fame, not-very-smart (I suspect no teenager would be seen with it) quite small screen. The large green button for "Thank" is far too easy to hit accidentally. I've raised this complaint before to no avail (will try and find a link in a moment), but as the previous editor has said it's really frustrating that there's nowhere civilised to discuss mobile edit problems - I was directed to a mail group, the last thing I want to try to cope with on that tiny screen. Why is there no talk page or feedback page for discussion of the mobile interface? (Why can't I see stub templates? If I'm stub-sorting, I know that if I don't see the stub template text when I've hit "Next" then I must have typed a correct stub template, though it might well not have been the one I intended. If I really want to check I have to switch to desktop mode and stretch the image like mad to read the stub template. Why can't I just somehow opt in to seeing them, and other key items which are hidden in templates, eg hatted discussions on talk pages?). PamD 22:34, 11 August 2014 (UTC)
@PamD: I asked on IRC, and was pointed towards mw:Extension talk:MobileFrontend as the best place to give on-wiki bugreports and feedback. However, because you're using the "Beta on" setting, you might want to mention that, and/or skim through the few existing threads at mw:Talk:Mobile Beta. Hope that helps :) Quiddity (WMF) (talk) 18:47, 13 August 2014 (UTC)
  • Comment on why the mobile thank UI is the way it is: on desktop, one gets to thanks from the history page, which is extremely cluttered with very tiny text and target links that are easy to mis-click; on mobile, the thank button is a large, prominent green button that is nowhere near any other link/target. Forcing a user to confirm the thank action in this context feels, frankly, a bit patronizing and silly. As for the meta-comment about how mobile UI should always follow desktop UI – citation needed :) If that were truly the case, formatted-for-mobile sites wouldn't exist on the Internet, and we'd be back to the ~2006 days of only looking at tiny shrunk-down desktop sites on our phones. Maryana (WMF) (talk) 18:42, 14 August 2014 (UTC)
Hallo Maryana, Thanks for joining in here. A large button, very near the "back" button on my phone, just underneath where my scrolling finger hovers when I'm not scrolling, just where I might grab the phone to stop it falling if it slips out of my hand, is much more easy to misclick than a small link in a busy page on a desktop. Perhaps it's an age thing - people of a certain age, especially when editing in the small hours of the morning because they can't sleep, do sometimes lose concentration and the hovering finger falls on the screen, or the mobile slips out of the hand. Asking a user to confirm an action in this case is neither patronizing nor silly but extremely sensible and helpful. Other editors have experienced the same thing.
Or, if nothing else, at least let me switch the d**n thing off so that I don't have that big green button.
And talking of tiny shrunk-down desktop sites: is there any other way to check whether a stub tag I've just added is the correct one? Or to look at the edit contributions of an IP editor who's just made an edit to something on my watchlist? I hate having to use the desktop UI on my phone (do you know just how small a Samsung Galaxy Fame screen is?) but sometimes it's the only option. Apart from things like Moving files, which (as far as I know) just can't be done and have to go on the mental list of "Next time I'm sitting at the laptop...". I'm not sure what you mean about "the metacomment about how mobile UI shold always follow desktop UI": are you saying that I said that? Do you mean that stub templates, hatted threads, etc are just something I shouldn't expect to be able to see in mobile and it's silly of me to expect to see them? PamD 19:52, 14 August 2014 (UTC)

Notices abnormally large-sized?

Bug report VisualEditor
Mito.money Please app{}
Intention: I was just trying to fix a typo
Steps to Reproduce: # Clicked "Edit-beta" on the "Wartime" subheading
  1. The editing interface opened but the notice was abnormally shaped and words were not the right size
  2. I closed the notice-box and it disappeared.
  3. This was reproduced each time I tried to edit using VE on this page.
Results: Noticebox closed when the X was clicked
Expectations: Expected no notices at all, but if there was one, for it to be fully legible and not cover such a large part of the page
Page where the issue occurs Tunnel Railway
Web browser FF31.0
Operating system Windows 7
Skin Monobook
Notes: Screenshot at File:VE_notice_as_of_13aug2014.PNG
Workaround or suggested solution NA

Risker (talk) 01:55, 14 August 2014 (UTC)

@Risker: Not repeatable because Tunnel Railway is no longer today's featured article. I started to edit Xeromphalina setulipes, which is now TFA, and saw the same notice, except it was fully legible. -- John Broughton (♫♫) 04:50, 14 August 2014 (UTC)
I have made a small change to make this work better. The problem is really here that the edit notice templates were never designed to work in any other environment other than a full size edit window. Especially the TFA notice has an exceptionally wide image that will take up all the space available. I have thus hidden this image for now. This is one more argument why we need edit notices as a core software feature instead of an en.wp hack. —TheDJ (talk • contribs) 09:47, 14 August 2014 (UTC)
It's not just TFA notices that do this. I asked User:Edokter for his thoughts about it back in March. So far, my favorite solution is "page/edit notices should be properly integrated into MediaWiki core", as someone mentioned above. Whatamidoing (WMF) (talk) 20:06, 14 August 2014 (UTC)

I am not sure whether this is a bug or if the feature is so contrived so as to make it impossible to understand, but I can't get it to do anything sensible. Clicking on an unlabelled external link brings up an interaction box with the link in it. Clicking the link brings up another box with an "add label" option. Clicking this just converts the link to a bare url, still with no meaningful label. Clicking on a bare url does not have the add label option so I fail to see how that is supposed to work at all. SpinningSpark 13:51, 11 August 2014 (UTC)

@Whatamidoing (WMF): - It's understandable that there is some confusion here, given the dialog that VE provides to edit an external link of the form [url], which is what Spinningspark is talking about. In fact, the dialog is very misleading, and points to the need for a different approach to adding or changing labels for external links.
In the "Simple link" dialog, the "Add label" button actually means "Make the above url into a label, and then you can change it on the main VE editing page, if you want." That's too much text for a button label, of course, but it emphasizes the current VE approach to changing external link labels: you can only do it on the main page, you can't do it via a dialog. It also emphasizes how easy it is to misunderstand what "Add label" means.
Here's what might happen, in the Simple link dialog, if (let's say) you change http://example.com to My example and click "Add label". What is displayed to the reader (the label) is http:My example, and the url has also been changed to that as well, which certainly isn't what a person would expect.
The Simple link dialog should have two fields (input boxes): one showing the (editable) url, and one to change (or add) the label. There should be three buttons: Cancel, Done, and (at the bottom) "Copy url to label field"
More generally, VE should not punish editors who want to change a visible label on an external link, but don't realize they can simply edit the label directly on the main VE page. If such an editor clicks on an external link, and then on the icon displayed, he/she should see a dialog that shows both the underlying url and the current label, with the option of editing either. The current Link dialog should be changed.
[Also, a small programming problem: clicking on "Add label" closes the Simple Link dialog (that's fine) and then scrolls the window so what is shown is the top of the page (that's wrong).] -- John Broughton (♫♫) 23:53, 13 August 2014 (UTC)
I think that this is fundamentally the same problem as the section below. Whatamidoing (WMF) (talk) 20:17, 14 August 2014 (UTC)

Defaultsort - VE still unhelpful

Tracked in Phabricator
Task T71568

Returning to VE after months away, I try to add a DEFAULTSORT to The Stingrays (1980s band). It's hard work. Eventually I find it, by clicking "Page Options", "Categories" (well, not, I didn't find that quick route at first but went via "advanced", as I was concentrating on DEFAULTSORT and not thinking of looking under "Categories").

And then, ah it's all coming back to me ... I'm faced with the page title in a little box labelled "Options" "Sort this page by default as": and I can't edit what's displayed there, nor copy and paste it from anywhere else in the article, so I have to handtype it (and of course what's there disappears when I start typing). Then click on "Apply changes." At least with this one I can remember how to spell the title - but it might have been something much less memorable, much less easy to spell correctly.

In the old editor: copy, paste and edit the required sortkey (often the article title, from which "The" is to be moved to the end; sometimes something with one or two diacriticals to be ironed out); highlight, select "DEFAULTSORT" from the Wikimarkup options displayed below the edit window, and there we go. Spot the difference.

Will I continue using VE? I'll try a few more edits, but then go back to using the old editor which makes life so much easier for me. I'm not resistant to change, but I don't see why I should struggle with VE when there are so many basic problems which make it more difficult for me to work - and these are things I pointed out last year but they're all given low to zero priority. VE may be aimed at attracting gormless newbie editors, or those who want to do Galleries and Chinese language, but it's useless for my sort of wikignoming. Does it make me feel appreciated, wanted, etc? Guess. PamD 13:41, 12 August 2014 (UTC)

OK, one or two things have got better! It's brilliant that I can now right-click on a link within VE and "Open link in new tab" to check where it goes, and I'm pretty sure that I couldn't do that before: thanks. PamD 13:53, 12 August 2014 (UTC)
But I can't do that with a reference, if I want to check what it says while editing the article: bad news. PamD 15:30, 12 August 2014 (UTC)
Re links: there is now also an "Open" button in the link inspector, which opens the target of the link in a new tab.
Re references: in the near future you will be able to click on a reference and see the first part of the text of the reference in the callout that appears. This already works for links, but for references it just says something like "News" or "Journal" right now. You can, however, double-click the reference to open the reference editor. Depending on the type of reference that'll either give you mini-VisualEditor with the contents of the reference in it, or a form. The form may display a preview of the rendered reference in the future.
As for DEFAULTSORT: it's a bit of an advanced feature, you kind of have to know where it is. That's true for the wikitext feature too, though, you have to know that it exists and how to use it, or see its usage on other pages and figure out what it means. Advanced features have a learning curve in every piece of software. Maybe there's a way we can make this (or other things) more discoverable, but VE and the wikitext editor are quite different, so I think we'll always have the situation where experienced wikitext users will have to relearn/rediscover a few things here and there when they start using VE.
As for copy/pasting the sortkey from the page title: maybe we should prefill the DEFAULTSORT box with the page title so you can start with that and edit it. Somewhat relatedly, there's a complaint elsewhere on this page from someone who wants to be able to move dialog boxes off to the side so they can see what's underneath.
As for continuing to use VE or going back to the wikitext editor: right now VE doesn't cater to power users as much as it does to simpler use cases. I hope that we can eventually get to the point where we're also catering to advanced use cases and making power users' lives easier, but right now we're not quite there. But thanks a lot for giving it a try and sending us your feedback! Do check back from time to time, we're changing and improving things all the time. My goal is to eventually get to the point that people use VE just because it works better for them: you should use the tool that works best for the job at hand, so VE should strive to be that. --Catrope (talk) 02:47, 13 August 2014 (UTC)
User:PamD, I can't reproduce the part about ""Sort this page by default as": and I can't edit what's displayed there, nor copy and paste it from anywhere else in the article, so I have to handtype it (and of course what's there disappears when I start typing)". I can edit what's there, and it doesn't disappear when I start typing (unless I first select the current contents). Can you double-check this to make sure it didn't get fixed in the update that happened a couple of hours ago, and remind me of your browser/OS if it's still a problem? Whatamidoing (WMF) (talk) 20:22, 14 August 2014 (UTC)

Editing Obama; "1 notice"

Tracked in Phabricator
Task T45013

I saw the watchlist notice that developers were looking for people to bang on VE a bit more, so I thought I'd give it a shot. First I went to Barack Obama and clicked EditBeta, and VE hung. Specifically, the light blue "progress" bars near the top right of the screen pulsed for 20 seconds, and then my browser (Firefox 31.0/Windows 7) presented a "Warning: Unresponsive script" message.

Text of the warning message

Text of the warning message:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=Base64.js%7Ceasy-deflate.core%2Cdeflate%7Cext.visualEditor.base%2Ccore%2CviewPageTarget%7Cext.visualEditor.core.desktop%7Cjquery.visibleText%7Cmediawiki.api.edit%7Cmediawiki.feedback%7Coojs-ui%2Crangy%7Cunicodejs.wordbreak&skin=vector&version=20140811T031829Z&*:79

I then clicked "Random article", wound up at Bziv, and tried to edit it with VE. A popup "1 notice" appeared at the top right, and couldn't be clicked on. That's a rather old bug, isn't it? Any ETA on getting that one fixed? If I recall correctly, every time an admin tries to edit an article they are presented with a spurious "1 notice" message. 28bytes (talk) 22:27, 12 August 2014 (UTC)

That last thing is something very english wikipedia specific and you are only seeing it because you are a sysop. It's due to our page notice system. I don't think it's a good idea that the team spends too much time on that right now. —TheDJ (talk • contribs) 08:17, 13 August 2014 (UTC)
I wouldn't argue with you on the priority of this, but dismissing a problem because it is something "non-standard only on English Wikipedia" is a tad misleading. Enwiki is by far the largest Mediawiki project and developments that do not work properly on enwiki are not much use. It is not just one project amongst many, it is the main course. Developers should ensure that nothing on enwiki gets broken by a new feature, or at least that there is some local solution to any issues. SpinningSpark 13:12, 13 August 2014 (UTC)
Yeah, it being limited to "just" English Wikipedia isn't very comforting, I'm afraid. It's annoying and happens on every single article I try to edit with VE. 28bytes (talk) 17:32, 13 August 2014 (UTC)
There are three proper solutions as far as I can see. Don't use VE if it annoys you too much, remove the page notice code from English Wikipedia, or wait till the page notice code is added in proper software (as was proposed by staff at Wikimania). Those are the only 3 proper sustainable solutions as far as I can see. —TheDJ (talk • contribs) 20:21, 13 August 2014 (UTC)
Gah, and now I did let all that community drama get the better of me. apologies, I should not be so rude. —TheDJ (talk • contribs) 20:23, 13 August 2014 (UTC)
No worries, TheDJ, we all get annoyed from time to time. :) Regarding VE, I doubt it will be my main editor (I prefer working with wikitext), but there was a watchlist notice this week asking folks to test it, so I did. I figure if they didn't want feedback, they wouldn't have requested it. 28bytes (talk) 20:39, 13 August 2014 (UTC)
Thanks for trying it out, 28bytes. This is a known problem, but it doesn't appear to be something that can be truly/permanently fixed inside VisualEditor. I'd like to see this feature integrated into MediaWiki properly. Whatamidoing (WMF) (talk) 20:40, 14 August 2014 (UTC)
OK, thanks. 28bytes (talk) 20:50, 14 August 2014 (UTC)

Adding categories: cramped display

Tracked in Phabricator
Task T71574

I added several categories to my article. Two of them turned out to be redlinked so I had to clear them up afterwards, because I struggled! The problem is this: the input box for "Add a category" isn't enormous (some categories are very long) but it gets presented alongside the last category added, if this has a name up to some limit of x characters. So if you try to add a category to Alf Cooke printworks and the last cat added was "Thomas Ambler buildings", the system reckons there's room for another one alongside it and only offers a very small input box, so that "Grade II listed buildings in West Yorkshire" is mostly hidden and you only get to see the first and last few letters. Please put each category on a new line.

But trying to check back on this I've found weird behaviour: I clicked on "Page option", "Categories", looked at what I'd got, hit "Cancel". That suite of actions should have a nett zero effect, right? Wrong. If I repeat it, I find I've got a double display of categories. And next time, a third listing of them. Not nice. ... Ah, I see this second problem is "Category duplication bug (display)" above, and supposedly being fixed in next few days. Good. But the input box size problem remains, unless it's so closely associated that it'll be being fixed at the same time? PamD 16:32, 13 August 2014 (UTC)

Thanks for this note. I've added the request. Whatamidoing (WMF) (talk) 21:26, 14 August 2014 (UTC)

A good feature - identifying links to dab pages

I like it: the drop-down menu of pages to link to shows me which ones are disambiguation pages or redirects. Now that is an improvement, and should reduce the number of accidental links to dab pages. There are some good things about VE. PamD 16:37, 13 August 2014 (UTC)

Thanks for the feedback. I've wondered whether identifying redirects is actually useful for internal links. (It's extremely important for creating redirects.) By labeling "Examples" as a redirect for normal [[links]], are we going to end up with more links like [[Example|examples]]? Whatamidoing (WMF) (talk) 21:37, 14 August 2014 (UTC)

Cannot reuse a citation multiple times in the same edit.

Here's a sandbox which demonstrates the problem. Try it for yourself. --99of9 (talk) 12:20, 13 August 2014 (UTC)

Per this discussion this is likely to be fixed tomorrow. Mike Christie (talk - contribs - library) 12:28, 13 August 2014 (UTC)
Thanks User:Mike Christie I hope so. --99of9 (talk) 13:16, 13 August 2014 (UTC)
It works for me now. Please post if it isn't working for you. Whatamidoing (WMF) (talk) 20:42, 14 August 2014 (UTC)
Yes it worked for me too. Thanks. --99of9 (talk) 03:50, 17 August 2014 (UTC)

Wikitext error message

Tracked in Phabricator
Task T53751
Declined

In VE edit mode, when I click on the indicator/icon of a (hidden) comment (an orange ball with a white exclamation point inside), I get a popup window with an icon and (part of) the text of the comment. I want to edit the comment, so I click on the icon/popup. Next, I change the text. So far, so good. Finally, I click "Done". And ... a warning message is displayed in the upper right hand corner: "Wikitext markup detected. You are using VisualEditor ..." . I hate to be impolite, but: WTF? -- John Broughton (♫♫) 04:23, 11 August 2014 (UTC)

John Broughton, is this reproducible in multiple places? I had one paragraph giving me that error last week, and there really was wikitext in it (I'd deliberately nowiki'd a code). Even if I didn't touch that sentence, I kept getting that error on that one paragraph. Whatamidoing (WMF) (talk) 18:13, 11 August 2014 (UTC)
@Whatamidoing (WMF): - There in fact is some nowiki'd text in that paragraph. So let me redo my posting (and I've changed the section heading):
  1. Why does VE warn me about nowiki'd text that already exists? I'd understand if this were new text, but it's not.
  2. Why does VE warn me only when I change something within the specific paragraph that contains the nowiki'd text. If I change anything else (including hidden comments) anywhere else on the page, I get no warning.
  3. Why does VE give me that warning if, in that paragraph, I (a) modify a hidden comment or (b) insert a citation/reference, but does not warn me, if, in that paragraph, I create a link? [I've only tested these three things.] -- John Broughton (♫♫) 22:26, 11 August 2014 (UTC)
You have reverse-engineered our wikitext warning code with impressive accuracy :) . The wikitext warning code is pretty hacky right now, because it's hard to check if any given change a user makes introduces wikitext (it's contextual: typing a single bracket is not wikitext, except if it's next to another bracket; an equals sign is fine, except if it's next to another equals sign and it's at the beginning of a line; etc.). So right now what is does is check whether the paragraph that you touched contains something that looks like wikitext. This explains #1 (blames you for pre-existing wikitext) and #2 (but only if you get close enough to it) above, but doesn't explain the difference between 3a and 3b. If anything, I'd expect those two to be reversed.
As for 3a vs 3b, if you can give us a detailed example that we can use to reproduce that difference, that would be great, because then we can file a bug for it and fix it. As for 1 and 2, I don't know if we have a bug filed for that yet, but we should probably have one. I think we can probably make it better by checking if the paragraph looked like wikitext before you changed it; we have some unrelated code coming in soon that should make that easier (right now it would be laborious to figure out what the paragraph looked like right before you changed it). --Catrope (talk) 00:16, 13 August 2014 (UTC)
@Catrope: I'm withdrawing point #3; I now think that VE is consistent about warning when any dialog is completed within a paragraph with wikitext. But I do consider #2 to be a problem worthy of a bug: VE should be able to distinguish old wikitext from new - that is, it should be able to tell that text that existed, before the edit began, which already had surrounding nowiki tags, is different than something that did lacks these tags. It's not like Parsoid strips off the nowiki tags during conversion, is it? -- John Broughton (♫♫) 22:13, 13 August 2014 (UTC)
This (which you said is #2, but I think you meant to type #1?) appears to be T53751, which was unfortunately WONTFIXed for performance reasons. Whatamidoing (WMF) (talk) 00:02, 14 August 2014 (UTC)
Yeah, I see it's currently marked as WONTFIX because it sounded pretty much impossible at the time, but I think I'll probably be able to do something about this in the next few weeks. I may not be able to fix it completely, but I'm pretty sure I'll be able to make it happen less often. --Catrope (talk) 21:05, 17 August 2014 (UTC)

Deleting tables

Tracked in Phabricator
Task T71706

If I select a portion of text that includes a table and delete the selection the table disappears with it. However, on saving the page, the table is still there. There is also some similar odd behaviour when repeatedly pressing delete in a table cell and the material being deleted crosses a cell or row boundary. I realise that tables in VE are not fully implemented, but this kind of mess shows that for sure VE is still not ready for mainspace. Features should fail gracefully, even ones that are not implemented yet. SpinningSpark 15:55, 18 August 2014 (UTC)

BTW, at Wikimania i picked up that some external party had done some design for table editing, which was enthusiastically received by the development team. This probably means that work starting on table editing might be a bit closer to arriving than was anticipated some 4 weeks ago. —TheDJ (talk • contribs) 16:42, 18 August 2014 (UTC)

Page options menu gets cut off

Tracked in Phabricator
Task T71707

The page options menu gets cut off, making you scroll to see what the items say. The menu seems to be fixed to the button instead of shifting over to fit on the screen. Firefox 31, Windows 7, Monobook:Jay8g [V•T•E] 19:17, 17 August 2014 (UTC)

Filed a report for this. —TheDJ (talk • contribs) 16:46, 18 August 2014 (UTC)

Mess while editing a Further reading section

Someone try to edit this with VisualEditor. It's a mess -- it suggests to edit these templates in a big pile instead of separately. I can't possibly discern which book is where. Gryllida (talk) 23:47, 17 August 2014 (UTC)

Yes these are very complicated template structures. Would you have ideas on how to improve the representation of this complexity ? —TheDJ (talk • contribs) 16:43, 18 August 2014 (UTC)
If VE is editing template parameters, and the template parameter meets the parsing definition of a template itself, can it treat it the same way it treats a template in the rich text interface -- allow you to click on it and recursively bring up another template editing interface? Mike Christie (talk - contribs - library) 17:32, 18 August 2014 (UTC)
It's not editing template parameters. It's a complex transclusion, in this case, a series of nested templates, and some of the templates are supposed to be applied to all of the internal ones. VisualEditor necessarily sees it as one block that contains many parts, rather than a series of unrelated parts.
The simplest workaround is not to use {{refbegin}} to change the font size. (Some of our users with poor eyesight would probably appreciate this anyway.) Another workaround is to apply the font change as a proper span tag rather than as a series of templates that each apply partial HTML codes. The solution that's eventually going to be implemented is to improve the design of VisualEditor's advanced transclusion editor. However, that's likely to take a long time. If you've got ideas about how to improve the design, then please post your ideas. Whatamidoing (WMF) (talk) 20:53, 18 August 2014 (UTC)

Wikilinking is cumbersome

Tracked in Phabricator
Task T71711

I am finding that wikilinking is very disruptive to the workflow in VE. The wikimarkup of double square brackets allows links to be inserted without breaking the flow of typing. In VE I must first stop typing, then select the text I want to link, then click link, then select the link, then click to close the dialogue. It is disruptive because it forces going from keyboard to mouse and the text insertion point has to be moved while selecting the link. The VE system is good for suggesting links to use, but when I know perfectly well what I want to link I don't want to bother with all that.

It would be good if the double square brackets were autocorrected to a link by VE. An autocorrection facility could have numerous other uses if it were implemented. I can see user defined autocorrection having many benefits as well. SpinningSpark 09:35, 16 August 2014 (UTC)

There's an equivalent keystroke sequence in VE to the "double bracket, linked word, close double brackets" sequence in the wikitext editor. For example, if you're typing the sentence "K2 is a mountain" and you want to wikilink "mountain", type this: "K2 is a ", then Ctrl-K, then "mountain", then <enter>, then <enter> again. Same number of keystrokes as before. If you want to pipe the link, one way to do it is "mountain", then Ctrl-K, then type the name of the target page, then <enter> twice. Mike Christie (talk - contribs - library) 12:25, 16 August 2014 (UTC)
Thanks for the info, but that failed on the very first attempt at using it. I did not need to contrive an example to break it, this is actually the very first thing I tried. In attempting to write
What actually came out was
On attempting it again, but this time clicking "done" after typing instead of "enter" I got
which as well as defeating the object of using keystrokes only is obviously still not right if you hover over the links. It seems that unless the link wanted is the first link in the list, one will always be forced to break off typing and select the correct link. There appears to be no way to force selection of the link "as typed". SpinningSpark 13:13, 17 August 2014 (UTC)
You're right that I hadn't thought about spaces in the displayed text name. I'm a keyboard shortcut user, so I typed in a couple of variations on the links you were creating to see what my fingers would automatically do. To get Republic of Vietnam I typed "Republic of Vietnam" Ctrl-Shift-LeftArrow Ctrl-Shift-LeftArrow Ctrl-Shift-LeftArrow Ctrl-K <enter> RightArrow, which worked. Then I tried the same thing, but instead of just hitting <enter> immediately I typed "Republic of Vietnam" in the dialog box. I got "Republic of Vietnam Navy" as the link target (not sure what happened to the Airborne Division, but this is essentially what you got). So in this case there is a fast way to do it, by simply not typing anything, but that's not a general solution when you want to pipe and the pipe target is not the first on the list. In that case I suspect the fastest way is to use arrow keys to scroll to the right place on the list (but see below; I think this will be rare). In neither of your examples was this necessary for me. I suspect you're on a different browser/OS combination than I am, though, because I get slightly different results from what you describe, so I can't be certain that what I describe would work for you.
I thought it would be worth doing some speed tests, so I compared two sequences that created the text "The Republic of Vietnam". In VE, the fastest seems to be: "The Republic of Vietnam" Ctrl-Shift-LeftArrow Ctrl-Shift-LeftArrow Ctrl-Shift-LeftArrow Ctrl-K "South Vietnam" <enter> <enter> RightArrow. That last "RightArrow" is to unselect the link text so that continuing to type does not erase the link. I timed myself adding five of these links in VE and five in wikitext: it took me 49 seconds to add five wikitext links, and 61 seconds to add five via VE. I don't think I could get much faster with either, so I would say it's about 10 seconds to add a complicated link in wikitext and 12 seconds in VE. It would add one or two additional seconds to arrow down to a particular item in a list and select that.
This isn't a big enough difference for me to prefer wikitext, but I could see it influencing others to prefer it, so I thought about what changes to the UI would speed up this interaction. Here's one suggestion:
  1. When exiting the VE link dialog, don't leave the link selected. There seems to be no benefit to doing so, and it adds a keystroke (RightArrow) on exit to avoid deleting the link.
I was also going to suggest that we add a shortcut key inside the VE link dialog that means: "Take whatever text I have typed, assume that it should be left exactly as typed (i.e. don't pick the checkmarked one off the list), and jump back out of the link dialog". However, I had some trouble coming up with an example where this would add value. It would require that you're piping the link (otherwise you can just hit <enter> as described above, bypassing the whole issue of selecting from a list), and it would also require that you are typing something that is not the actual target -- in other words, you're typing a redirect or dab name, which is unlikely if you're piping; or you're typing something that is ordered lower on the list than the bare text you typed, which isn't particularly common. An example is "Manchester", which is lower on the list than "Manchester United F.C.", so if you're redirecting a link to Manchester you would have to select "Manchester" when the list pops up. A single DownArrow would do the same thing, though, so I'm not sure a shortcut key is worth it.
I think the enhancement mentioned above is worth requesting. Can you see any other way to improve the user interaction on the link dialog? Mike Christie (talk - contribs - library) 16:47, 17 August 2014 (UTC)
Ok, I accept that it is possible to do this with keystrokes (but the sequence you gave at the beginning doesn't work, at least in Firefox). However, my complaint is that it is not "linear" within the activity of typing. I would like it to be like the insertion of italics or bolding which use Ctrl-I and Ctrl-B respectively. That is I would like "Ctrl-<foo> <link foobar> Ctrl-<foo>" where the link can be complete with #anchor and pipe etc as necessary and without something getting in the way trying to interpret what I already know perfectly well what I'm doing. SpinningSpark 18:04, 17 August 2014 (UTC)
Or even more generally, why not have a Ctrl-<foo> that escapes into wikitext until another Ctrl-<foo> is entered. That could get around any number of other shortcomings of VE and make it much more acceptable to those that currently don't like VE. SpinningSpark 18:08, 17 August 2014 (UTC)
That's the obvious solution, as I argued right at the start. Unfortunately the architectural choices made by the developers appear to have made that approach pretty much impossible. It was clear right from the start that the architecture was flawed, so we're where we are. No amount of additional work is going to change this sow's ear into a silk purse. Eric Corbett 18:27, 17 August 2014 (UTC)
I can see why some people would like a feature such as you describe. I was just trying to see if there was an equally easy way to do what you wanted within the current VE approach. @WhatamIdoing: What do you think of the enhancement suggestion above -- to leave link text not selected on exit from the dialog? It would cut out a keystroke and I don't see any value to the current behaviour. Mike Christie (talk - contribs - library) 02:51, 18 August 2014 (UTC)
I think it's a good idea, and with any luck, we'll also convince them that the cursor belongs at the end of the word that you just typed (and linked) instead of at the start of the word.
Feel free to remind me if I don't get a bug number posted here within the next couple of days. WhatamIdoing (talk) 04:01, 18 August 2014 (UTC)
This is now T71711.
What are people thinking about the "don't bother me with the search results, just link exactly what I typed" idea? Whatamidoing (WMF) (talk) 19:26, 18 August 2014 (UTC)
Tracked in Phabricator
Task T71716
Seems a bit of an overcorrection. I would rather say that the dialog should not auto select a DIFFERENT page if there is an exact match to a redirect.. perhaps it should not autoselect at all when opened via a keyboard command and just let the user explicitly select something from the list if he wants to use the suggestions. There is a strong separation between pages and redirects pages now in the suggester, which in general is a good thing, but NOT in this specific situation of for instance trying to enter "Republic of Vietnam", which is an exact match, yet ignored by the autoselection logic of the dialog. —TheDJ (talk • contribs) 20:26, 18 August 2014 (UTC)
That's a good idea no matter what's decided about how to link efficiently. Whatamidoing (WMF) (talk) 21:08, 18 August 2014 (UTC)

Old bug? Reference in explanatory footnotes missing

Tracked in Phabricator
Task T52749

Last year i reported (bugzilla:50749): a problem with references in explanatory footnotes (when you add a (sfn) template inside an (efn) template). The error was marked as fixed, but has probably reappeared? Please check, example article is Otto I: it should have 63 references, VE does show only 62 references - the Thompson reference #18 is missing. Thank you. (P.S. browser is actual FF with Windows XP) GermanJoe (talk) 22:54, 18 August 2014 (UTC)

Thanks for the note, GermanJoe. I've re-opened the bug for you. Whatamidoing (WMF) (talk) 00:08, 19 August 2014 (UTC)

Junk "if !supportLists" injected + table destroyed

Tracked in Phabricator
Task T71821

In this edit, junk was massively injected by VE and the existing table has been destroyed by VE. --NicoV (Talk on frwiki) 11:15, 19 August 2014 (UTC)

It looks like another round of copying from MS Word, only with a different kind of brokenness. I'll post a bug number after a while. Whatamidoing (WMF) (talk) 22:47, 20 August 2014 (UTC)
Tracked in Phabricator
Task T71822

Hi, in this modification, a language link was moved inside a title by VE. --NicoV (Talk on frwiki) 17:33, 19 August 2014 (UTC)

This looks like another round of "editing next to an invisible item". VisualEditor didn't "move" the interlanguage link (which probably ought to be on Wikidata); the editor unwittingly typed new material next to it. There's no way for editors to avoid doing that unless they can see that there's something (invisible) on that line. There's probably a bug for this, but if I can't find it, I'll file another. Whatamidoing (WMF) (talk) 22:52, 20 August 2014 (UTC)

Doubled article title following a VE edit

Tracked in Phabricator
Task T71857

I edited High Frequency Active Auroral Research Program using VE (actually a fairly pleasant experience - cut-and-paste worked well, and so did creating a new cite web citation). When I saved my edit, the result is what is shown in the screenshot - the title of the article is repeated in a smaller font below the normal title.

I did a second edit to confirm what I'd seen. (Mac OS, Chrome, Vector). I'm not inclined to believe this has something to do with my selecting, as a preference, the gadget "Display an assessment of an article's quality as part of the page header for each article", but I note that for the sake of completeness. -- John Broughton (♫♫) 03:15, 19 August 2014 (UTC)

It appears to be a conflict between VE and the gadget "Add an [edit] link for the lead section of a page", which I suppose you have enabled. Someone ought to fix the gadget. — This, that and the other (talk) 09:53, 19 August 2014 (UTC)
Yes, disabling the gadget appears to solve the problem in Firefox. Safari doesn't seem to be affected. (I've seen triple titles in Firefox.) I'll leave a note at the gadget's talk page about this. Whatamidoing (WMF) (talk) 22:41, 20 August 2014 (UTC)

I filed this as T71857. The blame is split between VE and the gadget, but it's a lot easier to fix in VE. :) Matma Rex talk 16:32, 21 August 2014 (UTC)

Odd asterisk

If you use VE to edit Sirens of TI, you'll see an asterisk at the end of the "References" section. I can't figure out how to delete this using VE, and I also can't figure out why it's visible in VE edit mode (and wikitext edit mode) but not in Read mode. (Additional information: There was an external link after the asterisk, which I deleted.) -- John Broughton (♫♫) 20:32, 19 August 2014 (UTC)

I fixed it for you. The process is: Place your cursor on the line. Go to the List formatting menu. Choose the bullet list item (to de-select it/remove list formatting from the line). Save page.
The theory as I understand it (i.e., not extremely well) is that the MediaWiki parser suppresses such stray/empty lists, because readers don't need to know about that. VisualEditor displays them, because otherwise editors would be unable to (intentionally) remove unwanted blank list entries. This is another instance of VisualEditor being a rich-text editor rather than a WYSIWYG editor. Whatamidoing (WMF) (talk) 23:06, 20 August 2014 (UTC)
Thanks. Very helpful. -- John Broughton (♫♫) 16:41, 21 August 2014 (UTC)

Different behaviour for tab / shift+tab in template/cite dialogues

Further to Wikipedia:VisualEditor/Feedback/Archive_2014_3#Excess_tabbing_through_Cite_mini-editors (bugzilla:69512): In template / citation edit dialogues, the behaviour of ⇧ Shift+Tab ↹ is not tabbing through the info and delete icons, while Tab ↹ is tabbing through those icons. Which tabbing behaviour is preferable might be debatable, but in either case, ⇧ Shift+Tab ↹ should just do the opposite of Tab ↹. I'm using Vector / Chrome / Win 7 if that's relevant. - Evad37 [talk] 05:29, 21 August 2014 (UTC)

I get the same behavior in Safari and Firefox on my Mac, so it's probably happening everywhere. TheDJ has mentioned this on the bug, along with a suggestion for fixing both of these annoyances at the same time. Whatamidoing (WMF) (talk) 17:21, 21 August 2014 (UTC)

nowiki for single quotes

Tracked in Phabricator
Task T71950

When a single quote needs to be escaped, could VE escape only the single quote with the nowiki tags and not half the sentence ? Examples: La Horde sauvage (film, 1969), Archelon, ... --NicoV (Talk on frwiki) 09:34, 23 August 2014 (UTC)

Template trashed by VE

Tracked in Phabricator
Task T71865

Hi,

In this edit, VE completely trashed a template. It's easily reproduceable:

  • Edit the Infobox with VE template editor
  • In the "Parcours junior" field, remove the last two lines
  • Save the modification to the template
  • The template is damaged, VE has put some nowiki but not correctly to keep the template

--NicoV (Talk on frwiki) 10:06, 21 August 2014 (UTC)

The user was confused by the wiki markup for the table code and removed the "end of table": }}. This should improve as support for table editing and support for editing template fields that contain markup improves over the next few months. —TheDJ (talk • contribs) 13:37, 21 August 2014 (UTC)
TheDJ There's no table involved in the example: the user incorrectly removed the end of the template "deux colonnes" (which is used inside the infobox). So VE managed to escape the pipes but completely failed to escape the {{ which was previously the beginning of the "deux colonnes" template. The result is a completely trashed template. --NicoV (Talk on frwiki) 15:04, 21 August 2014 (UTC)
Template yes. I'll file an issue for seeing if the nowiki detection can be improved for this case of unmatched brackets. —TheDJ (Not WMF) (talk • contribs) 18:08, 21 August 2014 (UTC)

On testing this, I noted that on the French Wikipedia, the text a the top of the "show changes" box ("Relire vos modif...") is obscured by the "Revenir au formulaire d'enregistrement" button. After using that "Revenir" button, I notice the exact same thing on the "Enregistrer vos modificati..." screen, which is partially obscured by the "Enregistrer la page" button. Anywhere else? Oh yes, when I open the infobox, I see at the top "Infobox F..." with the rest obscured by the "Appliquer les modifications" button. And the same when editing a reference, inserting a comment (I think something is hidden beneath the button)...

NicoV, is this a new thing, or is it always like this? Does every single user on the French Wikipedia who wants to save anything with VE (not a common occurrence, but still...) get this very poor layout? Rather staggering, this. Fram (talk) 14:02, 21 August 2014 (UTC)

Fram, this is a long standing issue, reported a long time ago, even marked as High, but as usual, even if it gives an awful experience for new comers, its priority doesn't really seem so high. I think most people have simply given up complaining about VE, since most reports are marked as enhancements or minor, and stay open for so long... --NicoV (Talk on frwiki) 15:04, 21 August 2014 (UTC)
That's certainly what I've done, as things just don't get fixed in any kind of timely manner. Eric Corbett 22:03, 21 August 2014 (UTC)
For those who didn't click through to the bug report, "a long time ago" means "less than a month ago". This problem appeared when the new, word-based/anti-icon windowing system was deployed.
Whether the words overlap at the French Wikipedia depends on your font size. If you zoom in and out, you can make the problem appear and disappear at will. For languages that are unusually long, many titles are obscured; for languages that are shorter than English, it almost never happens.
Technically, the problem is with OOjs, not with VisualEditor. OOjs is not correctly changing to the shorter names that VisualEditor is designed to display in this situation. Whatamidoing (WMF) (talk) 23:54, 23 August 2014 (UTC)

Size of windows

In my view, for a bug with "High" priority, a month with nothing done about it is a long time, but it seems we don't have the same scale for what is a long time. At least, bringing again this subject changed something (the bug was reassigned to somebody else...). And what about dynamically sizing the windows so that texts are not truncated ? In the example, you can see the texts are truncated, but even the basic message about licence and copyvio is only very partially displayed (the scrollbar on the right seems to show that only about half the dialog box is displayed) --NicoV (Talk on frwiki) 07:43, 25 August 2014 (UTC)
When I read this orignally, I thought you meant that the scrollbar wasn't working—that even if you scrolled down, the full text would not be displayed. (It does, of course.)
I understand that it is not possible to re-size windows at the moment. The OOjs team needs to build that ability before the VisualEditor team can use it. Whether it's a good idea is something that could be debated. I don't think that filling the entire height of the screen would necessarily be an improvement (and even then, it might not be enough. Some wikis have put a surprising number of irrelevant things into MediaWiki:Wikimedia-copyrightwarning). Whatamidoing (WMF) (talk) 22:46, 25 August 2014 (UTC)

nowiki added in otherwise unmodified part of the article

Tracked in Phabricator
Task T71950

Hi, in this modification, VE added nowiki tags in a paragraph that wasn't modified by the contributor. As usual, the nowiki tags are not necessary, and even if escaping the single quote was necessary, there's no need to escape half a sentence when there's just a single quote. --NicoV (Talk on frwiki) 07:00, 22 August 2014 (UTC)

Sure the editor did not make a change to that section ? I think he tried to remove the space before Homo Sapiens..... —TheDJ (Not WMF) (talk • contribs) 07:13, 22 August 2014 (UTC)
Ah yes, missed that one. But the second remark stays: it's the single quote that needs escaping, not half the sentence. --NicoV (Talk on frwiki) 07:59, 22 August 2014 (UTC)
As I understand it, the fundamental issue is that software processes "strings" as discrete units, and that said strings do not always line up with natural "words".
A more graceful approach might be this: "celui d'<nowiki/>''Homo sapiens''". Or would you normally italicize all of that ("celui ''d'Homo sapiens''") in French? Whatamidoing (WMF) (talk) 00:03, 24 August 2014 (UTC)
The current result is ugly and completely counter intuitive for a human who will come after in wikitext mode. Even if VE deals internally with large strings, it should be smart enough to use nowiki on a reasonable scale.
In French, my preference would be "celui d{{'}}''Homo sapiens''" (using a template), immediately followed by "celui d<nowiki>'</nowiki>''Homo sapiens''" or "celui d'<nowiki/>''Homo sapiens''". I prefer with the {{'}} template, but as this template is wiki dependent, I would understand that VE produce a result with nowiki. Concerning "celui ''d'Homo sapiens''", I believe it is not a correct typography. --NicoV (Talk on frwiki) 07:37, 24 August 2014 (UTC)
Thanks, Nico. I suggested "celui d'<nowiki/>''Homo sapiens''" at the bug report, but I would not be surprised if they take your second choice (nowiki tags around the single quotation mark) instead.
This is technically Parsoid's problem, and they seem to be treating it as a general need to be more elegant in handling this. Hopefully that will mean that not only this instance, but also any related ones, will all get cleaned up together. I don't know what their other priorities are, so I can't guess how long it will take to get this handled. Whatamidoing (WMF) (talk) 22:55, 25 August 2014 (UTC)

Selection box goes over menus

Tracked in Phabricator
Task T71949
Screenshot

The selection box goes over menus, coloring them blue and making the covered sections unclickable. (Firefox 31, Windows 7):Jay8g [V•T•E] 17:32, 22 August 2014 (UTC)

Jay8g, I can't reproduce that on my Mac. Perhaps it's a Windows-specific bug? Or is it only intermittent for you? (I only tried a couple of pages.) Whatamidoing (WMF) (talk) 00:11, 24 August 2014 (UTC)
Whatamidoing (WMF): I tried again and found that this always happens if you are at the very top of the page, but if you scroll down at all (so the toolbar floats), it stops happening:Jay8g [V•T•E] 00:26, 24 August 2014 (UTC)
Thanks for the update, Jay. I've added that useful detail to the bug report. Whatamidoing (WMF) (talk) 22:57, 25 August 2014 (UTC)

Error saving to server: Empty server response

Tracked in Phabricator
Task T72010

Hangs when editing "Integrated circuit" page - section SSI, MSI and LSI - tried to remove redirect wikilinks to SSI, MSI and LSI (keywords). Chrome 36.0.1985.143 m, Win7 64bit Kozuch (talk) 21:08, 23 August 2014 (UTC)

Hi Kozuch, and thanks for this report!
I just opened Integrated circuit, so it's working for me at the moment. Can you tell me if you're still having problems with it? It might be a momentary glitch, but I'd like to know if anyone else is still seeing this problem. Whatamidoing (WMF) (talk) 00:21, 24 August 2014 (UTC)
Hi, I see my edit was saved, but probably was later than what my patience allowed me to wait for :). I was looking at page history before cancelling the edit save, but it was not there, probably shower up later. VE interaction definitely ended up deadly though (hung on the "saving" dialog and when I canceled it the above error just was quickly show and then dialog closed by itself. See https://en.wikipedia.org/w/index.php?title=Integrated_circuit&diff=622517186&oldid=622152913. --Kozuch (talk) 17:48, 25 August 2014 (UTC)
How strange. I've filed the report at T72010. Whatamidoing (WMF) (talk) 23:01, 25 August 2014 (UTC)

The latest Tech News says, with regard to VE, "You can now add colors to links in the editor using gadgets. You can do this to see links to redirects or disambiguation pages."

I'm not seeing such a gadget in my Preferences (specifically, in the Editing, Gadgets, and Beta tabs). Am I overlooking something? Has someone written a gadget to do this, but it's not in Preferences? -- John Broughton (♫♫) 18:07, 25 August 2014 (UTC)

No, it is a bit of unfortunate wording in the Tech news. It was stated that such a thing could now be written (as opposed to before, where it would have been impossible). —TheDJ (Not WMF) (talk • contribs) 21:03, 25 August 2014 (UTC)
The first step in publishing Tech/News is to re-translate it from English into Simple(r) English. The original statement was "Links in the editor can now be coloured in by gadgets if they are links to redirects or disambiguation pages." I haven't heard anything specific from the team about this, but I'm going to guess that User:Anomie's script (instructions in the VPT archives here), or something like it, is what they had in mind (although I believe that Anomie's script would have to be changed to work in VisualEditor). Whatamidoing (WMF) (talk) 23:40, 25 August 2014 (UTC)
@John Broughton: Yeah, sorry about that, someone simplified my words a bit too far and made it misleading and confusing. I believe that a Hebrew Wikipedia user had a script to do this, hence why we enabled it, but I'm not sure if there are any general gadgets on any wiki that do this yet. Jdforrester (WMF) (talk) 23:52, 25 August 2014 (UTC)

Utter waste of money

@Jdforrester (WMF): (and other WMF people) Why is the WMF, when it is not bullying through MediaViewer, failing with Flow or repeating all the previous experiences with Winter, still spending most of its developer money and resources on VE instead of on the wikitext editor?

On the French Wikipedia, which is probably the largest wiki-version where VE is the default, the results are that after more than a year of VE deployment, less than 10% of the edits are made using the default editor (VE) and more than 90% are made with the cumbersome, old-fashioned, outdated, editor-frightening wikitexteditor.[3]. In every single user group, including IPs and newly created accounts, is the wikitext editor more popular than the VE. The same applies (with slaightly different figures) to the Italian wikipedia[4], the Swedish one[5], Russia[6], Poland[7], ...

The reality is that after all the work you spent on VE, it simply isn't what the editors in general want or need. What probably many of them would appreciate though is some improvements in the wikitext editor, incorporating ideas and improvements from VE, like e.g. the file chooser, the template editor, and, er, that's about it I think. Plus some unrelated but much needed improvements, as indicated by e.g. the cries for help from the mathematics editors.

Are there any plans to match WMF spending and resource allocation to this reality? Fram (talk) 07:14, 21 August 2014 (UTC)

You know you won't get any answer, except maybe the development of a new special right to prevent contributors to say anything bad about WMF... Otherwise, I agree with your statement about how badly the resources are spent, while there are some rather easier things that could be accomplished to help all editors... --NicoV (Talk on frwiki) 10:11, 21 August 2014 (UTC)
My preferred view is the breakdown as a percentage of users in a particular group (anon,new,regular). Those present a less grim picture for anons on fr with about 34% of anons using VE, 17% of new users and 3% of regular users. I've taken the averages of percentages for the last month for a few wiki's
Site Anon New user Regular user
fr 34% 17% 3%
it 24% 15% 4%
sv 30% 10% 5%
ru 34% 11% 2%
en 0.003% 0.8% 0.6%
de 0.001% 1.7% 0.2%

Obviously figures are much lower for de and en where its opt in, but there is very little take up by regular users across the board. It would be interesting to see how many new users continue to use VE after a month or so if they decide to switch. Comparing results from 6 months ago might be interesting.--Salix alba (talk): 15:28, 21 August 2014 (UTC)

I was an early critic of VE, and continue to believe that it should have stayed in beta testing mode for at least another six months. But it has become significantly better (more features, fewer major bugs), and - as importantly - it's starting to have functionality that the wikitext editor doesn't (and can't) have - image searching, checking the validity of external links, easier creation of citations, etc.
It's going to be years - if ever - before VE is a better choice for the most experience (wikitext) users, particularly some power users doing wikignome chores. But that's not VE's target audience - it's those who have never edited Wikipedia. For them, today, I'd definitely recommend VE, despite its numerous shortcomings. Slightly buggy software, missing some advanced features, is still preferable (for newcomers) to dealing with gnarly text that looks like code.
So yes, the way that VE was introduced was botched, badly, and the VE team still lacks the openness and interactivity with the community that would not only build confidence but would better focus its programming efforts. But VE continues to improve, and eventually Wikipedia will be the better for it. -- John Broughton (♫♫) 16:53, 21 August 2014 (UTC)
John, why do you say that wikitext can't have some functionality ? I do believe that everything you have listed could be implemented in the wikitext editor, it would only require WMF to dedicate a small portion of the resources that have been allocated to VE development. In my opinion, many features could be added to the wikitext editor, probably at a lower cost, and for a much larger audience. --NicoV (Talk on frwiki) 17:19, 21 August 2014 (UTC)
Citations are on the list of planned improvements for the wikitext editor. mw:Citoid is intended to be useful everywhere, even though the immediate work has been integration into VisualEditor.
As for why the WMF is doing this, I suspect that the community's identification of a rich-text editor as the #1 product priority recommendation a few years back has something to do with it.
Salix alba, one of the problems with the "edits" numbers is that we call them "VisualEditor" and "wikitext", but it's actually "VisualEditor" and "not VisualEditor". If you add a tag via Twinkle, that's labled as "wikitext", even though the wikitext editor wasn't actually used. Looking at fr.wp right now, about 15% of the allegedly wikitext edits didn't actually use the wikitext editor. (I'm sure it varies; I just looked at the last 100 mainspace edits.) A similar trip through en.wp's RecentChanges page shows 27% of allegedly wikitext edits that were done by script, bot, undo, or other methods that aren't actually someone choosing to use the wikitext editor. I suppose it would be possible to make undo use VisualEditor (which it would, if VisualEditor were actually "the default", rather than merely being "available by default"), but why bother? It would make more sense to have accurate statistics that differentiate between "I choose to use this editor" and "I was using a script or tool instead of choosing which editor I wanted to use". Whatamidoing (WMF) (talk) 17:44, 21 August 2014 (UTC)
":::::As for why the WMF is doing this, I suspect that the community's identification of a rich-text editor as the #1 product priority recommendation a few years back has something to do with it. " In what way does that page, written completely by WMF people, represent the community and its priority recommendations? As far as I can tell, this is the vision of a few Wikipedia developers based on some nebulous research, some cherry-picked quotes from non-editors, and no real community input. One of the major forces behind this paper is still the main force behind most botched WMF software of the last few years. Oh, and you have at least one error in the rest of your reply as well: bot edits are explicitly excluded from the stats I linked to, so you shouldn't remove these from the wikitext editing percentages we are discussing. Plus, of course, things like AWB edits are equally useful as many VE edits, which are also often typo corrections and the like. That AWB (and its users) doesn't want or need VE doesn't mean that these edits shouldn't be taken into account in a comparison.
Finally, none of what you say explains one bit why the usage of VE isn't growing, if it is so good, or why the drop in new editors hasn't been reversed now that we have the long-awaited top priority intuitive user friendly modern tool. Apparently, somehow, it isn't working as predicted. Fram (talk) 19:58, 21 August 2014 (UTC)
More than a thousand people participated in the planning done on strategy.wiki. I don't find your name among the accounts there, so perhaps you did not choose to participate in that process, but "more than a thousand" still exceeds the number of WMF employees in 2009 by an order of magnitude. The page I linked is not the only page to identify a rich-text editor as a key priority. You will also find it mentioned in the strategy:Wikimedia Movement Strategic Plan Summary, under "Increase participation".
As for "why the usage of VE isn't growing", have you looked at the data? Whatamidoing (WMF) (talk) 23:49, 23 August 2014 (UTC)
"Have you looked at the data?" Whataamidoing, are you still trying deliberately to be as offensive and unhelpful in your replies as possible? I have looked at the data over the months, I have given the current data at the start of this discussion. You haven't given anything at all, but of course you know better and wwe have to believe you. How hard is it to provide links to what you believe is evidence, instead of sending us of on a wild goose chase? I can find [8], which lists things from 2010 as having the status "doing". Even better is this of course. Perhaps we can lay down a simple ground rule; any "information" you share without a link to evidence will be treated as false. Probably you refer to the 900 proposals, where you can probably find a few for a "visual editor". No good search system is given for these proposals, so it's a bit hard to tell. Oh, and the list of participants, is that this list where I can't find someone called Whatamidoing? Just checking... Fram (talk) 06:53, 25 August 2014 (UTC)
You presented links to data from a single point in time. You then ask why usage is not growing. It is not mathematically possible to determine whether usage is growing by looking at any single point in time.
I didn't choose to participate in strategy.wiki. I looked it over occasionally, decided that I didn't really care what the five-year plan for the WMF was, and left it to the people who did care—a group that apprently didn't include you, either, which brings us back to my original point: you don't actually know who made which proposals or how successful proposals were identified. You therefore might want to stop asserting that you know that building a rich-text editor was only "the vision of a few Wikipedia developers" with "no real community input". I'm perfectly willing to stick to the obvious facts: VisualEditor is being developed because a major, multi-project community consultation that involved more than 1,000 people spent more than a year talking about what the WMF should do for the following five years. They created a five-year plan that included the creation of a rich-text editor as a major priority. When said plan was duly adopted by the WMF's board, it set the WMF's priorities for the next five years, i.e., until the year 2015. So why are they still working on VisualEditor? Because 1,000 people in the movement talked about what the WMF should do, and they concluded that this should be done. The plan "expires" next year. Perhaps different priorities will be set then. Whatamidoing (WMF) (talk) 22:23, 25 August 2014 (UTC)
I presented data for a month, not a single point in time. I have seen the same data in the past, and they were similar then. So yes, as far as I am concerned and until someone presents better data, usage isn't growing. I have asked you (and the WMF in general) repeatedly for better statistics to base discussions on. But it seems that you prefer to criticize the one that does present actual data, without doing anything yourself.
As for your "obvious facts", I don't see any evidence for them. Links? Indications of how many people (and what groups) actually wanted VisualEditor? Even so, if after e.g. two or three years in your five year plan you notice that the supposed solution isn't producing the wanted results, and no improvements look to be happening (usage growth, editor retention, new editor recruitment, whatever), then just sticking to it "because we decided this three years ago" is a very bad business practice. At least LiquidThreads was abandoned when it turned out to be rubbish. Anyway, please start providing some form of evidence for anything you want to state as fact, if you want to convince people of your points. It suspiciously looks like thin air otherwise. Fram (talk) 06:55, 26 August 2014 (UTC)
@NicoV: I generally find debating counterfactuals ("what if X had been done instead of Y") to be not all that useful. But in this case, I want to point out that with wikitext editing, the MediaWiki software doesn't understand what's happening until either (a) a preview is done or (b) a page save is done. That makes it impossible, in wikitext editing, to have a generalized interaction with editors (if they do X, then the software does Y, to help them). It also makes it impossible for editors to get instant feedback (as in, for example, moving or resizing an image). That is why Parsoid was written, as a new underlying basis for editing, and why VE has taken so much time to create (because it can't build on the wikitext system).
Again, I'm not trying to defend the process by which VE has reached its current state. I'm just saying that VE is now perhaps 70% or 80% of being a virtually flawless (albeit still limited) piece of software. Nor am I saying that the VE team will make the right choices to get to 100% (as opposed, say, to giving priority to the Chinese version of VE, which after all is in the VE team's annual plan, and so is clearly more important than fixing minor VE user experience problems that affect hundreds of language versions of Wikipedia). I'm just saying that the VE team, as unresponsive and misdirected as its software development process may be, is still improving VE, so VE will get better. -- John Broughton (♫♫) 17:54, 21 August 2014 (UTC)
It would struggle to get any worse, and it's an absolute disgrace that it's unavailable to users of IE. Eric Corbett 22:11, 21 August 2014 (UTC)
@Whatamidoing (WMF): You have a point about semi-automated edits. I've just used the data from the dashboard so it might be an idea to ask the stats team to add this data. I suspect this will not change the anon and new editors as they will not be using these tools. The dashboard stats exclude bots so the correction factor would be smaller. In the last 500 mainspace non-bot edits 13 were reverts (includes Twinkle and huggle), 8 undone, 18 hotcat and 2 AWB, 41 in total. Lets call this 10%. If we adjust the percentages to exclude semi-automated edits it may change the values for VE edits by regular editors on fr/it/sv/ru by half a percent upwards.--Salix alba (talk): 21:32, 21 August 2014 (UTC)
Analytics will be reassigning some projects soon, so now is probably not the optimal time to ask for this sort of change, but it is definitely on my list once we know who the 'new' person to ask is. Whatamidoing (WMF) (talk) 23:49, 23 August 2014 (UTC)

Internal links with no text (just a nowiki tag)

VE link dialog
Link dialog in the wikitext editor

After more than a year of VE being made available on most wikis, we still see internal links with no text added by VE (just a nowiki tag instead of the text), like in this edit ([[Boom Fm|<nowiki/>]] and [[Roger Blackburn|<nowiki/>]]). When will this bug be fixed ? --NicoV (Talk on frwiki) 09:40, 23 August 2014 (UTC)

I've added screenshots of the link dialog in (a) VE and (b) the wikitext editor, because I believe this is an underlying problem for the type of problems pointed out by NicoV. I think it's clear that the wikitext dialog is better. (Though personally I'd reverse the sequence of fields, so that the dropdown selection box for wikilinks - and yes, it's available in both, but doesn't open automatically in the wikitext dialog - is at the bottom, where the dropdown won't obsure the display text.) (And I prefer "Done" as a button label, and its placement in the upper right corner of the dialog, as is done in VE, but this isn't the main issue.)
I'd really like to hear why anyone might think the VE dialog is better. Or, to be more specific, why it's undesirable, or technically not possible (or very difficult), to have the VE dialog show both fields (parameters), rather than just one field/parameter. -- John Broughton (♫♫) 21:34, 23 August 2014 (UTC)
User:Jdforrester (WMF) will have to tell you the rationale for not offering a separate field for the link label. Whatamidoing (WMF) (talk) 00:19, 24 August 2014 (UTC)
@Jdforrester (WMF):, do you remember if there was a rationale for that James ? I notice that even Google docs isn't that sparse with UI fields :) —TheDJ (Not WMF) (talk • contribs) 09:44, 26 August 2014 (UTC)

Category additions with VE are FUN!

Tracked in Phabricator
Task T71927
Tracked in Phabricator
Task T72025

Open a random page in VE. My luck of the draw gave me Zprdeleklika. Use the three lines button to get to the categories. You have two of them. Cancel the category screen. Open it again. You now have four categories. Cancel. Open. 6 Categories...

Now, add one. Whichever one you add, you get it as many times duplicated as you have done to the pre-added ones.

Let's try something. I don't know if everyone will get the same results, but again add a category. Start with typing e.g. "1995 es". Perhaps you will get a scroll bar to the right (I don't always get this for some reason). Click the scroll bar button at the bottom (to scroll down). Oops, there goes the selection list... Now, when looking through the few suggested categories, something extremely strange happens: the tool proposes some completely made-up ones. In this case, I get Category:1995 establishments in 1995 as a suggestion. Other tries gave me Category:1991 estabilshments in Belgium (sic!), Category:1992 estabishments in Indonesia (again sic!) and Category:1998 establishments) (with the final round bracket, sic).

Now, I cancel. I open the cats again. Oh, all the cats I added before the cancel are still there? So what was the point of cancelling? Oh well, then I just open one I don't want, and use the trash can icon. Perhaps use it twice? Three times? No, nothng happens. Perhaps I need to use the "apply changes" instead? Ooh, nice, the top of the cat frame starts to display slowly moving diagonal stripes, as if something is happening. And it goes on, and on, and on... Cancel? Too late, you're stuck!

As a user of VE, you have no way of knowing which cats exist and which don't. I fully understand that the possibility to add non-existing cats exists, this is necessary. But the system should never suggest cats which don't exist. And it should use a workable interface, obviously, not what we have here.

Basically, the category interface of VE totally and utterly sucks. Completely. More than a year after VE was implemented as the default editing environment. The general arrogance of some important people at the WMF is staggering when one takes into account the abysmal track record they have in implementing new tools and communicating with the editor community. Things like this only make people less willing to give them the benefit of the doubt. Fram (talk) 14:44, 21 August 2014 (UTC)

The doubling of categories is a bug scheduled to be fixed shortly, per Wikipedia:VisualEditor/Feedback/Archive 2014 3#Category duplication bug (display). Problems with redlink categories have been noted here, and there are related bug reports: Wikipedia:VisualEditor/Feedback/Archive 2014 3#Displaying categories, particularly redlink ones. -- John Broughton (♫♫) 17:38, 21 August 2014 (UTC)
And the invention of new cats by VE, that's a new one? Or just one that hasn't been reported yet? And the complete breakdown of all functionality? (Not a question for you, John Broughton, your help is appreciated). Fram (talk) 20:01, 21 August 2014 (UTC)
The duplication bug seems to have gone together with most of the other problems, the very peculiar "let's suggest cats that don't exist and don't make any sense" one clearly remains, I just got a suggestion for Category:1895 establisANONYMOUS IS LEGIONhments. Has ANONYMOUS hacked Wikipedia or VE? Anyway, can anyone else duplicate these very strange cats? Just try anything, and after a few trie syou are bound to get very strange categories in your suggestion list. :-)
Fram, I'm reproducing the problem with the strange cats: If I try adding a category starting with "1895 es", the categories suggested are: "Category:1895 essays" (good!), "Category:1895 esta6blishments" (bad!), "Category:1895 establisANONYMOUS IS LEGIONhments" (bad!), ... If I try with "19", suggestions are "Category:19", "Category:19$30s in Irish sport", "Category:19(new single digit number between 4 and 5) 8 births", "Category:19)) deaths", "Category:19** births", ... Impressive !
And an other problem: when I try to click on the vertical scrollbar of the dropdown list of suggested categories, the dropdown list simply disappears. The only way I've found to view what is after the 5th suggestion is to use the arrow keys, the mouse doesn't work at all. Win XP, FF ESR 17.0.2. --NicoV (Talk on frwiki) 09:44, 22 August 2014 (UTC)
Thanks. Now I'm at least certain that the problem is not with my machine, but really Wikipedia-based. How they have achieved this extremely bizarre behaviour is hard to see, suggesting things which don't exist (and have never existed) and have no relation to the article either seems to indicate some developer using too much narcotics :-) Fram (talk) 10:06, 22 August 2014 (UTC)
VisualEditor displays whatever search gives it. It would be useful to know if these problems can be reproduced anywhere outside en.wp. Apparently there were some problems with en.wp's search index recently. Whatamidoing (WMF) (talk) 23:56, 23 August 2014 (UTC)
Strangely (well, not really), the search never gives such results. Look e.g. for "Category:1895 est" in the search box, and you get the start of a long alphabetical list of existing categories. Do the same in VE, and you get the ridiculous results given above. Even if you explicitly search for the erroneous cats returned by VE, you are not able to get them as a result or suggestion in search. So the end result is that this is a problem that only exists when using VE, no matter what causes it. Fram (talk) 06:59, 25 August 2014 (UTC)
The question that needs to be answered is whether this can be reproduced anywhere else. So far, the devs (the ones who deal with search) say that their belief is that it was due to problems with en.wp's search index. If it can be reproduced at any other wiki, then the problem (a) likely has some other cause and (b) likely won't be fixed whenever the repairs on en.wp's search index are finished. Whatamidoing (WMF) (talk) 22:50, 25 August 2014 (UTC)
Whatamidoing (WMF), the behavior is similar in frwiki. I tried with "1", VE suggests fr:Catégorie:1 (ok), fr:Catégorie:1) Aménagement de l'espace (bad), fr:Catégorie:1.1.5 (bad), fr:Catégorie:1.13 (bad), fr:Catégorie:1.13.12 (bad), fr:Catégorie:1.1 Début de vie (bad), fr:Catégorie:1.2 Début de carrière (bad), ... (and the problem with using the mouse with the drop down list is also there). No one can do any test among the developers before saying it's a problem in enwiki search index ? --NicoV (Talk on frwiki) 05:08, 26 August 2014 (UTC)
On itwiki, with "1", it:Categoria:1 (good), it:Categoria:1.980 nascite (bad), it:Categoria:1.983 morti (bad), it:Categoria:1.992 nascite (bad), it:Categoria:1. F.C. Kaiserslautern (good), it:Categoria:1. F.C. Köln 01/07 (good). --NicoV (Talk on frwiki) 05:19, 26 August 2014 (UTC)
Thanks, NicoV, for doing the job of the WMF people. It's hard to believe that we have to convince people, including the community liaison, that bugs really are bugs, even when shown that no, it doesn't happen in search here. The logical order would have been "we from the WMF, with our developers and fabled team of testers, can't reproduce this elsewhere, so it seems to be an enwiki-only problem caused by the search engine". Not "the devs believe that it is caused by enw's search index", but "the devs have checked whether it is enwiki only". Pathetic. 07:11, 26 August 2014 (UTC)
@Fram: can you pretty, pretty please, try to be a little bit less cynical and hostile ? You are driving people away from this page and I don't like that. —TheDJ (Not WMF) (talk • contribs) 08:49, 26 August 2014 (UTC)
I think it is slightly less harmful to drive people away from this page, than to drive people away from Wikipedia, as the WMF is constantly doing. It is hard not to be hostile when you note a rather worrying bug, only to be repeatedly shrugged off, and to be told that the devs believe it is caused by the enwiki search engine, when a five-minute check would show this to be incorrect. See also the "waste of time" discussion above, where Whatamidoing (our esteemed community liaison) rejects any figures given, but is unwilling or incapable of providing any links to support her rosy vision. Well, at least she responds (even if no one gets any the wiser from it), which is more than can be said from the product manager. Then again, he isn't making things up, so it is hard to say what is the best thing for them to do. Get the WMF people to clean up their act (a hard task, I know), and I'll respond in kind. For now, they get a mild version of what they deserve. Fram (talk) 09:06, 26 August 2014 (UTC)
Then throw that in an email to them, or discuss it on meta or something, but try to tone it down a bit on this page. —TheDJ (Not WMF) (talk • contribs) 09:17, 26 August 2014 (UTC)
No. If they sprout nonsense, dodge questions, or generally make a fool of themselves and/or act very uncooperative here, I'll point it out here. People like Philippe Beaudette are aware of the problems. I don't care if they want to play on meta or elsewhere, as long as they stay away from here (or drastically improve their approach and attitude). Discussing this on meta would only lead to "you want them to lose their jobs" accusations (which, while well-deserved, is not something I'm actively pursuing, and would probably be useless as long as Erik Möller is working there anyway). I try to keep rubbish in all its incarnations out of Wikipedia, and that's enough for me. Fram (talk) 09:26, 26 August 2014 (UTC)
Well you are also creating some 'rubbish' in the process and I if it is your goal to keep it out, then you should consider if your actions match your goals. That's just my opinion and I'm sure you won't agree, but I have to say it anyway, because you are making me avoid this page and though I don't think too highly of myself, I do think that's not a good thing and that there must be others that are thinking the same... And I will address you on that. —TheDJ (Not WMF) (talk • contribs) 09:34, 26 August 2014 (UTC)
There's never been any question about whether it is a problem: the question has always been which component had the problem (i.e., in en.wp's recently-unhappy search index or not). I filed the bug report and contacted multiple devs in e-mail about it last Friday.
Nico, I very much appreciate you providing the fr.wp list, and marking the bad ones for those of us who don't speak French. Thank you. Whatamidoing (WMF) (talk) 23:12, 26 August 2014 (UTC)
@NicoV: Thank you, I'll file a report. I wonder if it is picking up red links, that are not categories, or categories that have 'shortly' existed and didn't get expunged or something... But that is speculation. —TheDJ (Not WMF) (talk • contribs) 08:49, 26 August 2014 (UTC)

I already found the cause, should be fixed in about a week or two. —TheDJ (Not WMF) (talk • contribs) 09:08, 26 August 2014 (UTC)

@Whatamidoing (WMF): you got thrown of course by the assumption that this would be 'search', but it is actually a filter on the list of categories, and the list of categories includes any category that ever existed. —TheDJ (Not WMF) (talk • contribs) 09:28, 26 August 2014 (UTC)
I don't doubt that your solution is correct, but the cause seems to be different, since categories like Category:19$30s in Irish sport don't seem to have ever existed at all. Perhaps they were once used in articles, that I can't check, but they never existed as categories. Fram (talk) 09:38, 26 August 2014 (UTC)
No, a category has nothing to do with the existence of a page name for that category. Technically speaking it is perfectly valid to have a category that doesn't have a page connected to the same title. So someone making a red linked category in a page, will cause the that entry to show up in the Categories table and from that moment till the end of time, that category will have 'existed'. —TheDJ (Not WMF) (talk • contribs) 09:49, 26 August 2014 (UTC)
This must be another one of those wonderful things that make category pages so special (like not being able to WP:MOVE them until recently). Whatamidoing (WMF) (talk) 23:12, 26 August 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback/Archive_2014_3&oldid=1086987271"