This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current main page.

1. Not particular to Citoid, and so certainly reported elsewhere, but still: It would be really nice, when one adds a citation, to have the new citation appear in the list of citations. It's particularly problematical to have the citations renumber themselves, in the body of the text, as they do, but to have the list unchanged (so now the numbers in the body of the text don't match what is in the list, by number).

2. It's baffling to have the cite icon (castle?) sitting next to the drop-down for cites, and the two of them not behaving the same way as the paragraph, list/indentation, and insert icons and their related drop-downs. By this, I mean that for those three other icons and their adjacent down-pointing carets, it makes no difference whether one clicks on the icon or the caret - one gets the same menu choices. That's not at all true with the Cite icon (clicked on, it opens a dialog, primarily for Citoid) and its adjacent pull-down menu (which lacks a "Cite by URL or DOI" option, but lists six other options).

I understand that (eventually) most people will use Citoid, most of the time, so being able to access it directly on the toolbar (by clicking the Cite icon) saves one click. Fine. But that's no reason to exclude Citoid from the pull-down menu accessible via the caret. If Citoid is not on the regular pull-down menu, it's quite possible that a lot of people won't find it.

3. Clicking on the Cite icon opens a dialog with Citoid, plus this link: "Or use the full citation dialog to fill in the details yourself". That link wording may be technically correct, but it's both verbose and unclear. (A menu list may, technically, be a dialog, but that's not how most people think of it). The wording "Or use another type of citation" is both shorter and clearer.

4. I'm not found of YYYY-MM-DD as a date; I'd rather use Month DD, YYYY. I understand that preferences do vary. But it's going to get really old, really fast, to have to change the date format, every single time I use Citoid, to my preferred format. Is there, or could there be, some way to set a preference, so editors don't have to change the format, every single time they use Citoid?

5. After this sequence: click the "Cite" icon, paste a URL, click "Lookup", and click "Insert", then VE displays the citation in (what appears to be to me, anyway) a dialog, with the option of clicking "Edit". If I'm not interested in editing that citation, then I assume that I should press [esc] to dismiss the dialog - that's what I do with other dialogs. Nope - if I press [esc], VE thinks I'm trying to exit VE, and asks me whether I really do want to exit VE, or not. Such inconsistency is disconcerting.

6. If I insert a citation using Citoid, and click somewhere to avoid the Edit dialog (or non-dialog), then decide I don't like the citation and click Undo, on the toolbar, the citation is converted to an empty Basic citation. It takes a second "Undo" to completely remove it. I don't understand why a single "Undo" doesn't remove it completely. -- John Broughton (♫♫) 02:51, 5 April 2015 (UTC)

Hi John Broughton,

1. Use <references /> rather than ((Reflist)) if you want this behavior. It might someday be possible to update templates on the fly (without completely killing performance), but this is not likely to happen any time soon.
2. I believe that every right-thinking editor agrees with you, including the product manager. But the word is that this will take months, not days or weeks. (The icon is a book with a bookmark, and I don't believe that anyone actually loves that one, either.) Feel free to add ideas to phab: T96118.
3. I don't think that it's actually taking you to the usual dropdown, but I like your suggestion, and it's now phab:T96119.
4. Screwing up date formats is being discussed, but it seems dubious. Are you primarily thinking about the date field and/or the accessdate field?
5. It seems works like the same as the link dialog, if you (just) select one and then press escape. Does anyone here think that pressing Escape should exit VisualEditor without saving? (If you've made any changes, your browser should catch it and ask you if you really mean to close it, so you shouldn't lose any work. If you haven't made any changes, it just exits without warning.)
6. I've never tried that sequence before. When I don't like it, I backspace over it. It also creates an empty <ref/> tag if you don't undo twice. This is phab: T96120.

Thanks again for all of your help. I really do appreciate it, and I apologize for being slow in getting these filed in Phabricator. Whatamidoing (WMF) (talk) 07:14, 15 April 2015 (UTC)

Re #5 above: I'm not crazy about Esc exiting VE, but I think it's OK. However, I think John is right to say that hitting Esc when you are apparently in a dialog feels odd. The user expectation is surely that Esc pops one consecutively out of a hierarchy of dialogs. Only when you're at the top level should Esc cause VE to quit. I suspect that the design concept is that some things are true dialogs and some are displays of attributes related to the point the cursor is at; the latter are not dismissed by Esc because the cursor hasn't moved so VE is at the top of its display hierarchy. Hence Esc dismisses VE, not the apparent dialog. I will get used to this behaviour but I think some users will stay confused for a while. Not top priority to fix, though; it does work and is internally consistent. Mike Christie (talk - contribs - library) 00:29, 16 April 2015 (UTC)

@Whatamidoing (WMF): Both the source date and url access date fields appear as follows: 2015-04-16. What I'm suggesting is that an editor be able to set an editing preference (presumably in the Editing tab of one's Preferences) so that when Citoid creates a date, it uses the preferred format. That may not be the ideal situation (per Wikipedia:Manual of Style/Dates and numbers#Formats, date formats should be consistent within an article), but it will reduce the amount of work an editor has to do to get the date into an acceptable form - because the English Manual of Style says that YYYY-MM-DD is generally not an acceptable style for dates within articles. Alternatively, I suppose, there could be a single default style for dates within a language Wikipedia, modifiable by administrators. But, again, YYYY-MM-DD is not acceptable for readers, and so editors using Citoid, in its current form, really should be changing one or both dates [accessdate isn't that important], every single time.

I note, for the sake of completeness, that the ideal solution is to allow viewers, when logged in, to specify the date format they prefer (including which calendar), the way that Microsoft Excel allows one to specify the visible format for a date while keeping the underlying date in a consistent format. And, of course, the Wikipedia community would decide the displayed format for readers not logged in, perhaps even varying by IP location? [Excel actually has three levels: what you see when viewing a cell, what you see when editing a cell, and the deep value - through how Microsoft set up the last of these is obviously subject to disagreement - see http://j-walk.com/ss/excel/usertips/tip028.htm , for example.] -- John Broughton (♫♫) 17:11, 17 April 2015 (UTC)

John, if Citoid is inserting YYYY-MM-DD, that's because the source provided the date in that format. Try something from the Christian Science Monitor or from the Reuters website. You won't get YYYY-MM-DD from them. (Citoid does determine the format for access dates, and that could be changed if every language didn't have its own idea of what is "acceptable for readers".)

The main problem is that we're not talking about a simple question of starting with a validated, consistent date format (e.g., what Excel actually stores in its spreadsheets) and changing its appearance. Intead, we're talking about having Citoid change, and therefore in some cases corrupt, plain strings of text. You can see the request at phab:T95016, but I'm dubious about it. I'd rather have ugly formatting on dates than the wrong date. Whatamidoing (WMF) (talk) 23:08, 27 April 2015 (UTC)

CorporateM, I have a question about your /Archive 2015 1#Minor quips report: Is there any chance that the material you're pasting contains a tab character? That would be phab:T74390. Does it move the cursor to the top as well? That's probably phab:T73728, previously seen only in Safari (Safari and Chrome are related, though).

Mike Christie, your problem with scrolling down after pasting is now phab: T97359

Thanks, Whatamidoing (WMF) (talk) 23:19, 27 April 2015 (UTC)

I'm not sure; I'll try to keep an eye on it. CorporateM (Talk) 01:18, 28 April 2015 (UTC)

When in VE it is possible to "drag" an image to reposition it within the article - so far so good. The anchor moves as expected. However, if I wish to move the image further up or down the article than is currently visible I should be able to move my cursor (while dragging the anchor-point) to the edge of the scrollable area and for the article to start scrolling. This currently doesn't happen. This means I have to move the image in increments - to the top of the currently viewable area, drop, scroll the screen, re-select the image, drag to the top, repeat... Wittylama 16:11, 23 April 2015 (UTC)

Wittylama, what's your browser/OS? This works for me (Safari/Mac), but when it happened last year, I believe it was browser-specific. Whatamidoing (WMF) (talk) 21:58, 27 April 2015 (UTC)

@Whatamidoing (WMF): - I'm on OSX 10.10 and Chrome 42. Wittylama 22:11, 27 April 2015 (UTC)

User:Elitre (WMF), do you have Chrome 42 and Mac OX 10.10? Could you try to replicate this?

Sure, my pleasure. See my report in the task. TL;DR, the only reliable way to make the page scroll is through the two-fingers scroll gesture. HTH, --Elitre (WMF) (talk) 13:36, 28 April 2015 (UTC)

Wittylama, could you try one more thing? Some previous reports were bi-directional, and for others the problem was only dragging up or only dragging the image down. Does it work in either direction for you? Whatamidoing (WMF) (talk) 23:30, 27 April 2015 (UTC)

BlueworldSpeccie (talk) 18:37, 7 April 2015 (UTC)

Could you explain a bit as to what you mean by "the citation numbers are off" - off in what way? I opened the article you mentioned, above, in VE; when open for editing, it showed 64 citations, the same number as visible when just in read mode. So it's not obvious to me what the problem is. -- John Broughton (♫♫) 17:17, 17 April 2015 (UTC)

@John Broughton: Yeah, sure. It is not that citations are missing its that the numbers are different. Sorry for not making that clear in my first post. I grabbed two screenshots from the article I mentioned above the first one is the normal page - http://picpaste.com/No_Ve_normal-utjPNVYh.PNG , and the second one is with after I clicked the edit button and VE was on - http://picpaste.com/With_ve_not-HAJpsbz3.PNG. BlueworldSpeccie (talk) 17:35, 17 April 2015 (UTC)

@BlueworldSpeccie: Thanks. My first thought was that VE was just processing citations in the wrong order. But no, VE is mispositioning citation number and their associated text. To pick one example, in the table "2010s singles", footnote 38 is the citation for the text "US: 439,000", and the text for citation 38 is "Country Album Chart News: The Week of March 12, 2014: Eli Young Band “10,000 Towns” Hits Top Of The Charts ...". In VE (editing mode), the footnote number next to the text "US: 439,000" is number 31, and the associated citation text is "Zac Brown Band - Chart History ... ". So the citation numbers remain correctly paired with their citation text, but the citation numbers are in the wrong place. And that, of course, is highly problematical.

@Whatamidoing (WMF): Scrambling the location of citations makes it impossible to determine, in VE mode, whether text has a reliable source or not. I nominate this bug as a VE blocker, if it isn't already listed, unless someone can make a persuasive argument that this is an edge case. -- John Broughton (♫♫) 23:28, 17 April 2015 (UTC)

The problem appears to be the use of the unsupported local template, ((Certification Cite Ref)), instead of the supported ref tags. Templates are not ref tags, and they don't get processed the same way. (They can't get processed the same way, or else you'd never be able to edit the template in VisualEditor.) If you want this template to work, then pull the <ref> tags out, and add the ref tags directly in the article. (You'll type <ref>((Certification Cite Ref))</ref> to use it in the wikitext editor—a bot can convert all the articles very easily).

You can test it here; when you open the page in VisualEditor and select the "[1]", it offers to let you edit the template. Whatamidoing (WMF) (talk) 02:51, 18 April 2015 (UTC)

@Whatamidoing (WMF): Edge case it is, then. Since the template was created (and the 6000+ uses of it apparently related to) a WikiProject, I've posted at the related page: Wikipedia talk:WikiProject Albums. -- John Broughton (♫♫) 22:58, 18 April 2015 (UTC)

@John Broughton: I found another one. And I don't think that it a music template messing up. here vs. here with VE. Look at the line "In 2008, the Kansas City Zoo was voted one of America's best zoos." The citation number changes from 2 to 1. BlueworldSpeccie (talk) 14:32, 22 April 2015 (UTC)

I think there's a connection with T52474. --Elitre (WMF) (talk) 15:07, 22 April 2015 (UTC)

(ec) Yes, both issues, "references in templates/infoboxes" and "references generated by templates", are mentioned in the linked Phab thread and have been known for 2 years now. I suggest to nominate this issue as VE blocker, as it hinders editing in many developed articles on en-Wiki. GermanJoe (talk) 15:25, 22 April 2015 (UTC)

+1 with GermanJoe. This should be fixed in VE, the templates work as designed and they work correctly in MediaWiki, there's no reason to pull the ref tags out of template simply because VE can't handle this. --NicoV ^{(Talk on frwiki)} 16:40, 22 April 2015 (UTC)

@Whatamidoing (WMF): With no further comments, I have suggested the Phab task as Q4 blocker (although I am not totally sure, I did it correctly ;) ). It would be great, if we could get some progress towards a solution on this issue. GermanJoe (talk) 13:58, 28 April 2015 (UTC)

You have successfully nominated the task. The list is pretty long this week, so I don't know if it will get processed tomorrow or next Wednesday. We'll see. Realistically, I don't think that you should expect quick action. It's a hard problem. Whatamidoing (WMF) (talk) 22:12, 28 April 2015 (UTC)

Mrjohncummings (talk) 23:17, 15 April 2015 (UTC)

Mrjohncummings, I had this problem last week, but not this week. Has this continued for you? Whatamidoing (WMF) (talk) 18:05, 22 April 2015 (UTC)

Hi Whatamidoing (WMF), yep I'm afraid so, the bar always freezes in the same place which looks to be just over 2/3rds full, I've tried both large and small articles. I just tried it with the up to date IE 11 on the same computer (Asus UX305 with up to date Windows 8.1) and I have exactly the same issue. Is there any other info that I can give that would be useful? Mrjohncummings (talk) 21:34, 22 April 2015 (UTC)

Mrjohncummings, does it happen if you're editing logged out/in a private browsing window? This link: https://en.wikipedia.org/wiki/User:Sandbox?veaction=edit will still work even when you're logged out. Also, can you open this link? http://mediawiki.org/wiki/User:Whatamidoing_(WMF)/Sandbox?veaction=edit

Based on the question they asked me for phab:T67365 last year, they'd also like to know whether there are any errors in the Javascript console. If you know how to look that up, then that would help. In the meantime, I've filed phab: T97346 about this. If anyone else is having this problem, even occasionally, please let me know! Whatamidoing (WMF) (talk) 22:33, 27 April 2015 (UTC)

Thanks Whatamidoing (WMF), no idea how to look for errors in the Javascript console, happy to look if you can tell me how. Mrjohncummings (talk) 22:50, 27 April 2015 (UTC)

I don't know how to do it in Chrome or Internet Explorer, either, but this page seems to have some information about what to type or click on in Chrome. If those directions don't work for you, then someone else may know the answer. We have several experienced people on this page, and Chrome is the most popular browser among Wikipedia users. Whatamidoing (WMF) (talk) 22:14, 28 April 2015 (UTC)

I wanted to add myself to a table of users, just like Wikipedia:VisualEditor/Feedback#Speed_check on this page. VE's table editing rocks, but I wasn't sure how to insert "SPage (WMF)". It would be nice to automate this, if I'm logged in VE could add Insert > Signature/Username > (menu or dialog of different signatureflavors). Note I don't know how to easily do this in wikitext either, using ~~~ creates a (talk) link as well. I scanned Phabricator and didn't see a task for this. Thanks! -- SPage (WMF) (talk) 20:25, 28 April 2015 (UTC)

Personally, I don't think it's a good idea to add such things to VE: first, signatures are almost never wanted on pages that can be edited with VE on wikipedia; second, it will probably only result in new users adding their signature in the middle of articles, giving again more work to others to clean up articles. --NicoV ^{(Talk on frwiki)} 20:54, 28 April 2015 (UTC)

SPage (WMF), you can't use VisualEditor on this page anyway, so you're stuck with wikitext. I'll create a line for you, and you can fill in your numbers. Whatamidoing (WMF) (talk) 22:08, 28 April 2015 (UTC)

In Flow's VE, they recently added a mention shortcut trough @ character, but that's a bit too easy to trigger outside of Flow. —TheDJ (talk • contribs) 06:20, 29 April 2015 (UTC)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

Is it possible to manually add the refname into the template as although it is irrelevant to VisualEditor users a source editor will find it easier to navigate through the references if the refname has a meaningful title rather than just a number?

Deubug (talk) 21:06, 30 April 2015 (UTC)

It's not currently possible, but it's planned for the future. Whatamidoing (WMF) (talk) 23:44, 30 April 2015 (UTC)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

I can't change the size or aspect ratio of the window.

Deubug (talk) 21:01, 30 April 2015 (UTC)

There are significant limits to what's possible (in wikitext). You can make these smaller but not wider, and you cannot control the aspect ratio. However, VisualEditor seems to be even more limited: you can't do anything, and what displays for me is (almost) nothing (in Safari—it depends on your web browser), although it appears that it will save correctly. I've added this to phab:T69265. Whatamidoing (WMF) (talk) 00:09, 1 May 2015 (UTC)

User agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; rv:11.0) like Gecko

I don't like this new editor because I can't do hyperlinks anymore because whenever I do a hyperlink it shows the website and not the words therefore I think the original was better than this.

Obdog (talk) 02:37, 4 May 2015 (UTC)

Hi Obdog,

You might want to read the directions at mw:Help:VisualEditor/User guide#Editing links. The easiest approach is to type the words first, and then select them and add the link (like you would do in a word processing document). However, it's possible to change the label afterwards; just click in the middle of what looks like the website, and type in what you want, and then backspace over the parts that you don't want.

The link tool is being re-designed. I would be interested in your feedback on the new version (look at the comments just above this). Whatamidoing (WMF) (talk) 17:43, 5 May 2015 (UTC)

In this edit, VE added useless sup and abbr tags around nothing... --NicoV ^{(Talk on frwiki)} 21:22, 5 May 2015 (UTC)

I made that edit to change the word on a wp:red link. It piped the link instead. This is a problem in my mind. How was I supposed to know that my edit would actually maintain what I realized was an incorrect link? How are newbies supposed to know? Maybe someone has thought long and hard about this and has a rational explanation, but I can't help but think the concept of piping links might need more explanation via a Visual Editor feature. Thanks. Biosthmors (talk) pls notify me (i.e. ((U))) while signing a reply, thx 17:35, 6 May 2015 (UTC)

Thanks for the note, Biosthmors. It's a known problem. They've tried a couple of different things, but it still needs more work. Whatamidoing (WMF) (talk) 20:00, 6 May 2015 (UTC)

Agreed! Thanks. Biosthmors (talk) pls notify me (i.e. ((U))) while signing a reply, thx 17:37, 7 May 2015 (UTC)

Help:Cheatsheet explains "piping" on the third line. It's sad to see VE fail to help with this simple concept. =( Biosthmors (talk) pls notify me (i.e. ((U))) while signing a reply, thx 17:39, 7 May 2015 (UTC)

The link tool is being re-designed. If anyone wants to take a look, then you can try it out at on mediawiki.org. This will arrive here next Wednesday. What do you think? Whatamidoing (WMF) (talk) 23:43, 30 April 2015 (UTC)

Actually, I'm a bit disappointed. If you edit a link with a destination already set, and switch from Search Articles to External Link and back, the destination disappears. Also, there's no cancel button.

Furthermore, if there's no relevant picture, what's the point of the placeholder image?

Finally, what I'd really like is two input boxes: one for the link text, and and on for the destination. -- Ypnypn (talk) 13:52, 3 May 2015 (UTC)

Ypnypn, I'm not sure about the placeholder image (on what they're calling the "context menu"). It's possible that they intend to have a preview of the link there someday. I'll ask and let you know if I hear anything interesting. Whatamidoing (WMF) (talk) 19:47, 6 May 2015 (UTC)

Ypnypn, I have an update: It is a preview system. If you go to mw: and try to make a link to "What", you'll find mw:What should I edit in the list of options, with a thumbnail of the page. Whatamidoing (WMF) (talk) 19:52, 6 May 2015 (UTC)

Article links still get immediately updated after editing (I don't even have to click "Done", leaving the window with "Esc" or clicking elsewhere also updates the link) - I still don't like this behaviour. Changes in the "edit link" window should be buffered, until the user clearly decides that they are OK and only then applied to the article. All other edit windows (cite, template, media) only cause updates, when "Done" (or "Apply changes") is explicitly clicked and they have a clear option to discard your changes, if something went wrong ("Cancel"). I don't understand, why this logical and save approach is skipped here just to save 1 click - especially when Visual Editor is supposed to be used by many inexperienced editors. GermanJoe (talk) 04:08, 4 May 2015 (UTC)

The general rule of thumb is that anything with an "inspector" happens instantly (links, math, galleries, etc.), and anything with a "dialog" (media, templates, citations) requires positive action. One of the interesting differences is that if you open a math or gallery inspector and close it again, they don't insert empty math or gallery markup. But unless you select a space, opening a link almost never creates empty markup (and if you do, it behaves like the other inspectors and fails to make a link). Whatamidoing (WMF) (talk) 19:47, 6 May 2015 (UTC)

Whatamidoing (WMF) Well, it's simple then: stop using an "inspector" and use a "dialog" instead... I'm not sure I've ever seen this VE notion of "inspector" in any other software, no wonder I feel it's totally not ergonomic. The closest think I can think of is dialog that would instantly apply what you're doing but only temporarily and you still have the option to validate (Done) or cancel (Esc). Why can't VE behave like most of the softwares out there ? --NicoV ^{(Talk on frwiki)} 20:16, 6 May 2015 (UTC)

Assuming inspectors with instant application of the changes are here to stay, "Cancel" in inspector windows should perform a proper rollback action (similar to the "undo" feature in the main window) to restore the last article status when the inspector window was opened. An "add link" window with 2 fields for visible text and piped link should be considered as well. GermanJoe (talk) 21:30, 6 May 2015 (UTC)

Something else I noticed. If I try to insert something in the middle of a sentence and place the cursor on the spacechar before a word, then 'insert link', it will highlight the entire word following it. This just doesn't make sense to me. And like many others, i think we should just show the display text in the Editor as well. Even Google drive does this. And the tabs for 'search article' and 'external link' feels a bit out of place design wise, they could use a bit more work... —TheDJ (talk • contribs) 08:44, 4 May 2015 (UTC)

TheDJ, I think that both of these need new items in Phab, but I need new information.

If you place the cursor on the space character before a word, and then 'insert link', what do you expect to happen? [[ ]] is invalid (so not that), but what would you like?

Is your concern about the tabs for 'search article' and 'external link', their appearance, or their labels (e.g., external links vs external URL), or something else? Whatamidoing (WMF) (talk) 19:47, 6 May 2015 (UTC)

Not very intuitive...

• The behavior with Esc is just awful, against any normal behavior, and will lead again to many errors in page.
• Please add a field for the displayed text also, that will probably help solving many errors made by users like [[2000|2015]]
• The behavior with the tabs is awful too: deleting what the user has typed is just against any ergonomics I've ever seen. Combined with the behavior of automatically validating what you've done...
• The behavior with Done button is awful also: if you click it when the list of pages is open, the text you have actually typed is discreetly replaced by the first text that is in the list of pages.
• ...

Honestly, it looks a lot like the first "design" of the special characters tool: not designed at all, not tested at all, ... I don't believe I can make really constructive comments with its current status.

This will arrive here next Wednesday: please, no !!!!

--NicoV ^{(Talk on frwiki)} 20:06, 4 May 2015 (UTC)

The behavior with the Escape key is the same as it has always been. I believe that the request for a two-field input system is the most frequently suggested change. Deleting what you just typed was recently filed (number in the list above).

I think that the last one is 'working as designed'. The idea seems to be that if you click "Done", then whatever link you selected from the list is the one that should be added. By default, that's the first one in the list. If you wanted a different link, then you should have made sure that a different link (e.g., a red link) was highlighted. But that only works if you realize that something is actually selected. I've suggested phab:T98393 as a way of making that most obvious. Whatamidoing (WMF) (talk) 19:47, 6 May 2015 (UTC)

Whatamidoing (WMF) I never selected anything in the list, it's VE that decided to pop up that list and apparently select something it (but not showing it) without me doing anything for this. The normal behavior of a dropdown box in any normal software is that the actual value used is the one in the text field, and when you actually select something in the list, then the value in the text field is replaced by the one you selected. Why choosing a behavior that happens in no other software ? --NicoV ^{(Talk on frwiki)} 20:21, 6 May 2015 (UTC)

When the link tool starts searching, it always auto-selects the first item in the list. It is showing the selection in an ugly medium-gray highlight, which IMO doesn't look like what any other software uses to select an item in a list. Whatamidoing (WMF) (talk) 22:58, 7 May 2015 (UTC)

Thanks for your quick feedback, Ypnypn, GermanJoe, TheDJ, and NicoV. Based on your comments, I have a fairly urgent question: Is it materially worse than what we have right now? For example, neither the current nor the planned have the oft-requested two-fields system to separate labels from their links, so the fact that it doesn't have that desired improvement makes it "just as bad as" rather than "worse than". Whatamidoing (WMF) (talk) 18:16, 5 May 2015 (UTC)

Of course the sky won't fall with this new version. But this tool's window design is inherently flawed. When you add complexity and new features to such a design, you just increase the existing flaw and the possibility for errors (which other editors have to fix later). Don't get me wrong, the approach with 2 tabs "internal/external" could work, but the layout and behaviour of the window needs to be re-worked per the above comments. If it's technically possible, I'd withhold this specific feature for now to allow more discussion and possible design changes. I understand the intended design with 1 field, but I am unsure if it will ever work in a safe, error-resistant and transparent manner - it's just not intuitive enough and doesn't cover all possible situations in a safe way. GermanJoe (talk) 19:09, 5 May 2015 (UTC)

I hadn't tried the new link tool till just now. I just had a go at it and spent maybe a minute and a half puzzling over it, and I am not at all sure how it's intended to work. I went back to the existing link tool and tried that again and confirmed that it seems a lot easier to understand. This is not just familiarity; I have never tried putting in an external link with VE, but seeing that that was clearly one of the options, I tried it in both systems. I failed on mediawiki.org and succeeded on en-wiki. I think the new dialog is a step backwards. The gmail link editor interface is not just a great model, but it's already familiar to many users. Please put in another vote in favour of something like that. Mike Christie (talk - contribs - library) 19:19, 5 May 2015 (UTC)

I also think that the new one is a step backwards, and will lead to even more problems than the current one. The current version is flawed also, far from being ergonomic, leading to many incorrect edits.

PS: I just tried with the current version, it has the same bug with clicking on "Done" when the list of possible pages is displayed: the typed text is silently replaced by VE with the first in the list. --NicoV ^{(Talk on frwiki)} 19:50, 5 May 2015 (UTC)

Mike Christie, one of the goals with the new thing was to help people figure out that you can add external links. If anyone has ideas about how to make that more obvious, then please share. Whatamidoing (WMF) (talk) 19:50, 6 May 2015 (UTC)

Whatamidoing (WMF) Just throwing ideas... A toggle to let the user says that the text is for an external link ? If you want something more automatic: when the user edits the target, VE decides if the target is rather an external link (things starting by http://, ...) or an internal link, and displays that information in a button/toggle. If what VE has suggested is not what the user wanted, the user can click on that information to force it to be an external or an internal link. --NicoV ^{(Talk on frwiki)} 20:26, 6 May 2015 (UTC)

Ugog Nizdast (talk) 08:56, 6 May 2015 (UTC)

Thanks Ugog Nizdast, this was filed last week. James Forrester put it on the list of this quarter's blockers, so it needs to be fixed soon. --Elitre (WMF) (talk) 09:41, 6 May 2015 (UTC)

Great, it seems to work now. -Ugog Nizdast (talk) 07:38, 8 May 2015 (UTC)

How do you use the ref label template using VisualEditor. See this diff for the messy result of an already frustrating edit.

Second, while attempting to put in this note, I tried to copy-paste the citation listed right after it. I selected it, but because there was only another template before it, and not text, I was only able to bring up a browser option menu "View this image," "copy image," etc., instead of a copy-paste menu. I've had issues with this before, but usually I can highlight some text in the selection as well and copy-paste and then just delete the text, leaving the citation. But in this case there was only the other template, which I didn't want to copy.--3family6 (Talk to me | See what I have done) 00:14, 5 May 2015 (UTC)

1. Why are you still using a citation template that the community has officially deprecated? Is this a leftover legacy for that page, or does it do something that you can't do any other way?
2. Is this reliably reproducible, or intermittent? As a workaround, did you try adding a single letter next to the template that you wanted to copy, and then trying to copy the letter and the template together? Whatamidoing (WMF) (talk) 17:47, 5 May 2015 (UTC)

1. I was unaware that the template was deprecated. I see that there is a notice at the top of the template doc, but I did not notice it at the time. I only used the template because I saw another editor use it recently, and I was trying to create a footnote, so I used it. I'll look through the Footnotes page to see how I'll update the notes for the article. I did figure out, though, how to use the template in VE.
2. I will try to see if I can reproduce it. That workaround which you suggested I think I've used in the past.--3family6 (Talk to me | See what I have done) 01:54, 8 May 2015 (UTC)

For the first question about Template:Ref label, Template:Efn works the same way, and has the same difficulty. You need to type in "1" as the parameter.--3family6 (Talk to me | See what I have done) 02:12, 8 May 2015 (UTC)

If the deprecated template doesn't do anything unique, then perhaps we should see about sending a bot around to replace it. (Since that hasn't already happened, then I'm going to assume that it isn't so simple.) But yes, any template with unlabeled parameters always accepts "1", "2", and so forth for the parameter names. 1 is the first parameter, 2 is the second, and so forth. I've seen people recommend adding those explicitly for wikitext as well, but I'm not sure what problems it's supposed to solve. Whatamidoing (WMF) (talk) 22:23, 8 May 2015 (UTC)

I used Citoid to create a citation using a url from the examiner dot com website, a website that is blacklisted - see Wikipedia:Spam blacklist. It was only when I did the final page save that VE objected - with a quite user-unfriendly message.

This is another opportunity for VE to be better than the wikitext editor. VE could validate a new url immediately upon its being added, rather than at the very end. VE could displayed a dialog saying something like "badurl.com is a blacklisted website. The url you added therefore cannot be used." Then clicking "Okay" (the only option) should cause VE to automatically delete the problematical url. (Dismissing the dialog, say with "esc", should be considered the same as clicking "okay".)

Or, at minimum, the VE existing error message needs to be improved. -- John Broughton (♫♫) 17:28, 7 May 2015 (UTC)

Does VE have access to the blacklists? Can VE have access to the blacklists? — Arthur Rubin (talk) 19:10, 8 May 2015 (UTC)

I don't know. Let's find out. One way or another, the workflow is bad and needs to be fixed. Whatamidoing (WMF) (talk) 23:08, 8 May 2015 (UTC)

Kerry (talk) 21:09, 9 May 2015 (UTC)

The answer will be (eventually) "whichever editor I most recently used", but that will unfortunately not happen before your teach your class. (It may not happen this year.) There are some ugly and/or complicated workarounds, but I think that for the purpose of your class, the easiest thing to do is to click "Create". A few Wikipedias have changed the new page messages to include a link to VisualEditor. That is seen if you click on an external link like https://en.wikipedia.org/wiki/Abcdef but not if you click on Abcdef.

VisualEditor, even when it is available by default, is not actually the default editor. The wikitext editor is the default. Therefore the wikitext editor is invoked every time that you open an editing environment without explicitly selecting VisualEditor. This happens not only in page creation, but also in reverting edits and reviewing diffs. Whatamidoing (WMF) (talk) 21:17, 11 May 2015 (UTC)

Kerry (talk) 20:56, 9 May 2015 (UTC)

Hi Kerry,

Thanks for this note. Do you need it to match that exact citation, including incorrectly labeling NLA as the publisher (it's really the archive)? Because if you just want something quick and easy, then it's really quick and easy:

1. Click on "Cite" (the word, not the dropdown arrow next to it—we have a design problem here that's being worked on).
2. Paste the URL (http://nla.gov.au/nla.news-article16680964) into the blank.
3. Click "Look up" to get everything automagically returned to you.
4. "Insert" the results (and save the page). You're done.

(See this example.) You can edit the content afterwards by clicking on the ^[1] number and then clicking the "Edit" button in the context pop-up menu. If you double-click on it, it will take you to the Basic reference dialog (useful if you need to add text or other templates at the end).

If you really need this to match, then it's possible but ugly. Here's the process:

1. Open the Basic reference form (from the dropdown menu next to the Cite button).
2. Insert > Template
3. Click the "Show options" button at the bottom. This takes you to the complex transclusions tool.
4. Click the "[ ]" button at the bottom (the tooltip says "Add content").
5. Paste your pre-generated wikitext in there.
6. Realize that the "Insert" button is still incorrectly grayed out (I'll go file that bug in a moment), so click the red trashcan icon to delete the empty "Template" blank above this.
7. Click the now-green "Insert" button to get back to the Basic Reference dialog.
8. Click the "Insert" button to insert the citation.
9. Save the page.

You can see the results here. I don't exactly recommend the nine-step process, but it works if you need to use it. You can edit this one by clicking on the same things, except that it's going to take you to the complex transclusions editor. Whatamidoing (WMF) (talk) 21:06, 11 May 2015 (UTC)

I don't personally need a workaround because I normally use the source editor. My problem is what do I teach Australian new users in the coming month in edit training workshops; I can hardly teach workarounds that aren't even documented in the user manual. WMF's strategic plan emphasises the need for relationships with cultural institutions and NLA Trove (a national initiative involving many Australian libraries) has got on board and supports Wikipedia with pre-format citations for all the books, journals, newspapers, photos etc in the catalogues of hundreds of Australian librarians. Trove is very well known among educated Australians and they come to Wikipedia training knowing about Trove and many will have seen that there is are Wikipedia-format citations (i.e. it is not possible to put the genie back in the bottle and pretend these preformatted citations don't exist). Can we add Cite Preformat which simply does what the open-book-with-red-bookmark does in the source editor - just takes the string and spit it out with ref tags or have a tick-box in Cite Basic to omit the nowiki tags or some other easy-for-the-user solution? Kerry (talk) 22:37, 11 May 2015 (UTC)

Kerry, I'm sure that everyone values NLA Trove, because it's a fabulous resource. What I'm trying to clarify is your sense of what your students need to be able to cite sources there. You seem to say that it's not good enough to directly support citing Trove itself; instead, you believe that the pre-formatted wikitext citations at Trove must also be supported. The reason that the pre-formatted wikitext citations must be supported in VisualEditor is because they exist. Did I get that right? Is there anything else? Whatamidoing (WMF) (talk) 23:34, 11 May 2015 (UTC)

Links to valid redirects are not handled well (I am fairly sure, that was discussed a few months ago):

1. Start editing Otto I, Holy Roman Emperor
2. Click on Magyars in the 3rd paragraph and start editing the link.
3. Selection list auto-selects Magyarsarlós as first entry in the search list (and overwrites the completely valid "Magyars" link!)

The search feature lists "Magyars" as possible alternative at the end of the selection list and recognizes it as redirect, but fails to select it. Editing a Wiki-link, the selection list must auto-select the currently active link (if it's a blue link), no matter if the blue link points to a real article or "only" to a redirect. In this context redirects need to be treated just like normal article links. GermanJoe (talk) 23:29, 7 May 2015 (UTC)

Actually I get

1. Magyarszerdahely
2. Hungarians
3. Magyars
4. Magyarszentmiklós
5. Magyarsarlós
6. Magyarszék

It suspect that redirects are always inserted into this list after their target.. —TheDJ (talk • contribs) 20:26, 8 May 2015 (UTC)

Let me go talk to Sucheta about this. She'll know more about the behind-the-scenes mechanics than anyone else on the team. Whatamidoing (WMF) (talk) 23:14, 8 May 2015 (UTC)

GermanJoe, I don't actually know that much more about what's happening, but what I learned is almost as good: Sucheta has fixed everything, and once it clears all the usual process, this problem will go away as the ugly bug that it was. She sends you her thanks. Whatamidoing (WMF) (talk) 23:37, 11 May 2015 (UTC)

Looking forward to it :). Thanks for the quick update. GermanJoe (talk) 23:42, 11 May 2015 (UTC)

I just added an empty section to an article[3] with a editorial note. When I used VE to edit the section, I noticed the editorial note was transformed into a tiny grey square exclamation point. I'm not sure newbies will comprehend what this signifies, or if they will even notice it. Is there any discussion on other mechanisms to show editorial notes? Thanks. Biosthmors (talk) pls notify me (i.e. ((U))) while signing a reply, thx 21:38, 8 May 2015 (UTC)

If it applies to the whole page, then you can use an WP:Edit notice.

Do you think that a different color would be a good idea? Whatamidoing (WMF) (talk) 23:11, 8 May 2015 (UTC)

I'd vote for an orange exclamation mark. -- John Broughton (♫♫) 23:00, 10 May 2015 (UTC)

Thanks for asking, Whatamidoing (WMF). I'd say it would be nice to do much more than make it orange. Sometimes editorial notes provide a lot of good information that helps future editors. Sometimes it's necessary to see that note in context with the wikitext. Editorial notes are sometimes placed at important spots within the article, where edits may commonly occur that go against consensus or wise editing practices.

Maybe we could make the exclamation point two exclamation points, and orange, with text in between that says "see editorial note". When you click on it, it might pull up the text in context with a small amount of surrounding wiki-text with the option to edit the editorial note? The current way seems to dismiss the value or potential importance of editorial notes. Biosthmors (talk) pls notify me (i.e. ((U))) while signing a reply, thx 13:45, 11 May 2015 (UTC)

Or once one clicks to activate VE, it could show the editorial note just in a different color, exactly where it is, with perhaps something else to designate that it isn't actually part of the visible text of the article from a reading perspective, but only an editing one. Biosthmors (talk) pls notify me (i.e. ((U))) while signing a reply, thx 13:48, 11 May 2015 (UTC)

Or just make them editable colored superscripts, and do away with the little box entirely. I think that would work nicely. Biosthmors (talk) pls notify me (i.e. ((U))) while signing a reply, thx 14:10, 11 May 2015 (UTC)

These are good ideas. Biosthmors, can you give me an example of a note that doesn't make sense unless you can see the wikitext? Whatamidoing (WMF) (talk) 17:13, 11 May 2015 (UTC)

The only example I can cite at this moment is in an infobox next to the field "alias": [4]. Ironically, these editorial notes were recently removed. They prevented a recent edit of mine, when I considered posting a nickname there a while back, but I didn't because of the note and explanation. I'm confident much better examples exist. Biosthmors (talk) pls notify me (i.e. ((U))) while signing a reply, thx 17:04, 12 May 2015 (UTC)

In that example, VisualEditor shows you the wikitext (as part of the parameter), and while I see that it's a relatively important message, I don't see why you would need to see the wikitext itself (i.e., not the hidden HTML comment, but actual wikitext markup) to make sense of the comment. Whatamidoing (WMF) (talk) 23:49, 13 May 2015 (UTC)

Just a minor bug. When trying to add a new category using the Wizard, I was trying to use auto complete from the drop down box. Rather than displaying the full name of the category University of Hanover alumni it just displayed condensed form "University ... alumi" making it really hard to see if I had the right category.--Salix alba (talk): 07:51, 12 May 2015 (UTC)

Thanks for the note. It's known and annoying, and I have no idea when that impossible situation will finally be fixed. Whatamidoing (WMF) (talk) 00:05, 14 May 2015 (UTC)

Kerry (talk) 23:01, 14 May 2015 (UTC)

Hey everyone, that A/B test that we talked about a while ago has finally been scheduled. They're going to start with a 24-hour pilot run, beginning a week from now, just to make sure that the logging software is working correctly. (There have been some problems with that.) About a week after that, assuming all's well, they'll do the real thing for exactly one week. User:EpochFail's running it, and you can follow along (everything's public) or ask questions about the methodology at project page on Meta. Whatamidoing (WMF) (talk) 00:07, 15 May 2015 (UTC)

When editing a section, I've noticed that the editing window does not normally position itself in the right place. So I need to scroll up or down to find the section that I want to edit. — Martin (MSGJ · talk) 12:15, 15 May 2015 (UTC)

MSGJ, I've been thinking recently that this is less reliable than it used to be, but I was thinking it might just be me (I've been having other problems). What browser/OS are you using? The last round of this had to be fixed separately in each browser. Whatamidoing (WMF) (talk) 15:47, 15 May 2015 (UTC)

Siddhant (talk) 01:14, 16 May 2015 (UTC)

@Siddhant: Thanks for the report! I think what's going on is that the link text used curly quotes, while the link itself used straight quotes. The two types of quotes are separate characters, so VisualEditor treats them differently. When I do the same thing using only straight quotes, VisualEditor correctly makes a non-piped link.

In the long term, it may be worth having VE automatically do things like turn curly quotes into straight quotes, but changes like that are almost always more complicated then they seem: for example, we'd have to make it possible for each project to customize its autocorrect rules (so that the English Wikipedia could turn all curly quotes straight, and the German Wikipedia could turn all straight quotes curly), which would be quite an undertaking.—Neil P. Quinn-WMF (talk) 21:03, 16 May 2015 (UTC)

When typing categories the suggestions are case-sensitive, which is a little bit annoying. Could they be made insensitive? Thanks — Martin (MSGJ · talk) 12:19, 15 May 2015 (UTC)

I don't have high hopes for this one (I think it displays whatever the normal search offers), but I've asked. If it's possible, then it would be great. Whatamidoing (WMF) (talk) 15:50, 15 May 2015 (UTC)

Unless I've misunderstood you, the normal search does do this. If you type Mosques in e in the search bar, the autocomplete will suggest Mosques in Europe and Mosques in Egypt regardless of the case of the "e". — Martin (MSGJ · talk) 08:53, 18 May 2015 (UTC)

Kerry (talk) 04:38, 16 May 2015 (UTC)

Thanks for this suggestion, Kerry. I've filed a task for this. Whatamidoing (WMF) (talk) 16:46, 20 May 2015 (UTC)

I keep pressing "enter" when typing in the edit summary and expecting it to save the page, but instead it puts a carriage return in the edit summary, which is not even possible to display. Please make enter be a shortcut to save page, like the source editor. — Martin (MSGJ · talk) 12:49, 15 May 2015 (UTC)

I do the same thing. There is a shortcut, but it's control ⌥ Option s (in Safari/Mac OS). The meta keys depend upon your browser and OS, so the quickest thing to do is to go to the list of Keyboard shortcuts (in the middle of VisualEditor's "(?)" Help menu and look at the list. The last item is for saving.

I still want plain old Return to work here. Whatamidoing (WMF) (talk) 15:54, 15 May 2015 (UTC)

I too press RETURN expecting to Save, but, I do this because it's a source-editor behaviour. It is not so clear to me that new contributors only using the VE will expect this behaviour and indeed they may expect the opposite behaviour (that is, that they can embed RETURN into the edit summary). I note that, since you need to use the source-editor to give feedback on this page, it follows that feedback is more likely to come from editors already very familiar with the source-editor who are not the users for whom the VE is developed. Indeed, it is not clear to me that there is any way that VE-only users can give feedback. Kerry (talk) 04:32, 16 May 2015 (UTC)

It looks like some of the devs are thinking along the same lines as you. Whatamidoing (WMF) (talk) 17:07, 20 May 2015 (UTC)

• FYI, I've proposed using control + enter (or command + enter for OS Xers) as a keyboard shortcut to submit dialogs like this, which has the double benefits of allowing enter to add new lines (which we may want to start displaying at some point in the future) and of following the behavior of a lot of other websites including Gmail, Facebook, and Google Docs (T98105). It's been suggested that we make the edit summary box a single-line text box instead of a multi-line text area (T54133). This would make it possible to save just by pressing enter, and would make browsers auto-complete the field by default. However, it would also make the field less usable: the larger text area seems to be more inviting to new users, while I've heard that single-line text fields tend to confuse people because they visually cut off summaries that exceed the length of the field and make it difficult to scroll back to see the overflow.Neil P. Quinn-WMF (talk) 06:16, 17 May 2015 (UTC)

  Deskana's comments on Phabricator are spot on. The edit summary is a single line of text and I've never seen a proposal to change this. Why would you present it to editors as a multi-line text and then just remove their carriage returns to make it single line? It is counter-intuitive. — Martin (MSGJ · talk) 08:51, 18 May 2015 (UTC)

  • Replacing the "editarea" with a regular edit box (regardless of its shape) has been a long-standing request. Whatamidoing (WMF) (talk) 17:07, 20 May 2015 (UTC)

There seems to be a miscommunication about a problem I brought up earlier. So, let's try again.

Situation: If someone using VE adds a blacklisted url, VE does nothing until the person tries to save the page. Then, in a dialog box titled "Something went wrong", the following error message appears, with the box being too small for the whole message, so the user needs to scroll down to see it all. And no, the message is not formatted - what is shown below is exactly what the user sees, though the line width is less.

((fmbox |type = warning |id = mw-spamprotectiontext |image = none |text = Your edit was not saved because it contains a new external link to a [[Wikipedia:Spam blacklist|site registered on Wikipedia's blacklist]]. * '''To save your changes now''', you must go back and ''remove the blocked link'' (shown below), and then save. **Note that if you used a redirection link or [[URL shortening|URL shortener]] (like e.g. 'goo.gl', 't.co', 'youtu.be', 'bit.ly'), you may still be able to save your changes by using the direct, non-shortened link - you generally obtain the non-shortened link by following the link, and copying the contents of the address bar of your web-browser after the page has loaded. ** Links containing 'google.com/url?' are resulting from a copy/paste from the result page of a Google search - please follow the link on the result page, and copy/paste the contents of the address bar of your web-browser after the page has loaded. * '''If you feel the link is needed''', you can: ** ''Request that the entire website be allowed'', that is, removed from the [[MediaWiki talk:Spam-blacklist#Proposed removals|local]] or [[meta:Talk:Spam blacklist#Proposed removals|global]] spam blacklists (check both lists to see which one is affecting you). ** ''Request that just the specific page be allowed'', without unblocking the whole website, by asking on the [[MediaWiki talk:Spam-whitelist|spam whitelist talk page]]. Blacklisting indicates past problems with the link, so any requests should '''clearly''' demonstrate how inclusion would benefit Wikipedia. )) The following link has triggered a protection filter:<strong> examiner.com/ </strong><br /> Either that exact link, or a portion of it (typically the root domain name) is currently blocked.

Apparently back in 2013, the developers thought they were providing users with a clear message in such situations - see https://phabricator.wikimedia.org/T52826 . As I hope is obvious from the above, the current message is anything but clear. Perhaps T52826 should be reopened? -- John Broughton (♫♫) 03:54, 20 May 2015 (UTC)

@John Broughton: Thanks for the report. The Mobile Apps Team ran into similar problems as this. Basically, extensions like the spam blacklist and abuse filter were designed under the assumption that you'd be using the desktop wikitext editor, and nothing else. It's extremely difficult to integrate things like VisualEditor and the mobile apps with these extensions. In fact, the abuse filter even caused the app to crash for a little while because of how erratically it behaved. These extensions need overhauling (which needs dev work), and a big chunk of the messages need rewriting across all wikis (which needs community work). It is actually a surprisingly large undertaking to fix this problem. In terms of what's next, it'd be better to file a new Phabricator task rather than reopen that one, because the original task to implement the functionality is complete, whereas you would like it improved. Hope that helps. --Dan Garry, Wikimedia Foundation (talk) 05:05, 20 May 2015 (UTC)

I'm surprised that presenting an identical interface to extensions such as the spam blacklist and the abuse filter isn't a requirement for VE. Surely we aren't going to require extension developers to be aware of two different editing interfaces?—Kww(talk) 05:25, 20 May 2015 (UTC)

@Kww: You're absolutely right that extension developers shouldn't have to write special code for each interface. Extensions should be modular. That's actually exactly what caused this problem; these extensions go too far in the other direction, and make a load of assumptions which are true if the user's using the wikitext editor and false otherwise, which leads to the problems I mentioned. As to whether it's a requirement or not for VisualEditor, I can't speak to that as I'm not part of that team. --Dan Garry, Wikimedia Foundation (talk) 05:28, 20 May 2015 (UTC)

I'd appreciate some detail on this one. It would seem to be an inherent requirement on VE that no other application could detect its presence. Of course, I've been surprised before by what would seem to me to be an obvious requirement that wasn't obvious to the VE team.—Kww(talk) 15:50, 20 May 2015 (UTC)

Right, John. That's a mess. Thanks for re-explaining; whatever the underlying limitations of the blacklist extension are, that needs fixing now. Whatamidoing (WMF) (talk) 20:43, 20 May 2015 (UTC)

I was testing mobile editing, and I have this shiny new tablet (Samsung Galaxy Tab 4 8.0). If I use Wikipedia in Firefox, the desktop version is identical to Firefox on the PC. Wikitext editing is just the same.

But it won't let me use VE. Even though Firefox for Android is as identical to Firefox for a PC as Mozilla can make it. Even "?title=Pagename&veaction=edit" doesn't work.

I've already chosen to opt in to VE, what's being overly helpful here and preventing me from trying this? - David Gerard (talk) 19:31, 9 May 2015 (UTC)

Do you want to use the desktop site, or do you want to use the mobile site?

On the desktop site, the browsers may be blacklisted. Let me see if I can dig up the browser list again. It's been months and months since I looked at it. Whatamidoing (WMF) (talk) 17:18, 11 May 2015 (UTC)

I'm trying to use the desktop site. As I noted, wikitext editing works just as expected. I'm assuming the tablet is blacklisted, though as I note there is no reason the browser couldn't run VE - particularly as nobody on en:wp is running VE without explicitly wanting to - David Gerard (talk) 20:34, 14 May 2015 (UTC)

I didn't see anything in the blacklist. I'll have to ask around. Most of the team is en route to the Hackathon in Lyon, so I'm not sure who I'll reach. Whatamidoing (WMF) (talk) 00:12, 15 May 2015 (UTC)

At your leisure :-) There should be some way to force it on ... I suppose I could play silly buggers with user agents - David Gerard (talk) 08:32, 16 May 2015 (UTC)

phab:T94725 is making me think that it's deliberately disabled. Whatamidoing (WMF) (talk) 21:49, 20 May 2015 (UTC)

I really like the order of the "new" edit bar (I say new, it's only looked like that since yesterday for me). The suggestion is, is there any way of making transcluded templates like the one used on the palmares section in this article (https://en.wikipedia.org/wiki/Dan_Craven) more editor friendly. I needed to fix a few things and went back to using wikisource because it was easier and more straightforward than using VE. Not a problem but I know you're trying to move to having VE be the first port of call. Red Fiona (talk) 12:42, 21 May 2015 (UTC)

You're right. The ((colbegin)) and ((colend)) templates did not behave at all well with VE. Perhaps it is easy just to use tables? Then you can just double-click the cells to edit them directly. I have done this on Dan Craven - what do you think? — Martin (MSGJ · talk) 14:52, 21 May 2015 (UTC)

Thank you very much. The only problem I can see (other than having to migrate all of the palmares sections over to tables unless there's a bot for that) is that while the colbegin/colend system automatically made the contents of the two columns as even as possible, this doesn't happen automatically with the table system (compare the two versions of the palmares section in my sandbox https://en.wikipedia.org/wiki/User:Redfiona99/sandbox), which could be a problem with some like say Tom Boonen (https://en.wikipedia.org/wiki/Tom_Boonen). Red Fiona (talk) 16:49, 21 May 2015 (UTC)

IMO the real solution is to make wikitext handle columns properly, rather than having all of these templates to add HTML. Whatamidoing (WMF) (talk) 17:33, 21 May 2015 (UTC)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.152 Safari/537.36

In the Candelaria massacre page it mentions that two police were convicted, then later in the "aftermath" portion it says that only one was convicted...

Maggiebpdx (talk) 19:52, 21 May 2015 (UTC)

Welcome to Wikipedia, Maggiebpdx! I've tagged the problem in the article, but I don't know the answer, so I can't fix it. If you do (especially if you have a WP:Reliable source for the information), then please WP:Be bold and fix it yourself! WhatamIdoing (talk) 20:35, 21 May 2015 (UTC)

Red Fiona (talk) 22:58, 23 May 2015 (UTC)

Thanks for your feedback, Red Fiona. T100018 is the relevant task. Best, Elitre (WMF) (talk) 11:12, 24 May 2015 (UTC)

This edit [5], VE didn't alert me that OpenWave was a redirect. (Fixed here.) I suppose for new editors they'd need to know what a redirect was, but as an experienced editor I found it disconcerting I had to fix my gratuitous and erroneous redirect afterwards. Not sure how we'd reveal this in the interface in a newbie-friendly manner ... but I would have liked some sort of awareness I was making a mistake - David Gerard (talk) 21:15, 24 May 2015 (UTC)

If I try that now, it tells me OpenWave is a nonexistent page. Is/was it the same for you? Other redirects seem to work, but I found another one which doesn't (LEXIS). I wonder if this has to do with camel case/upper case titles? --Elitre (WMF) (talk) 21:35, 25 May 2015 (UTC)

Using Cite news, I don't see a way to add a second author surname under "Add more information". Whereas the last3 - last9 fields are all supported, last2 isn't. Or at least it isn't obvious. Barte (talk) 20:05, 30 May 2015 (UTC)

@Barte: "last2" and "first2" are listed among the first few additional fields after "publisher", once you click "Add more information". Don't let the field label confuse you: all last name-fields are labelled the same as "Last name" (which should probably be changed). The "real" numbered field name is shown on the right side of the selection list. GermanJoe (talk) 20:48, 30 May 2015 (UTC)

Ah, I see it--thank you. What threw me was that I didn't get that additional fields are available in not one, but two steps: "Add more information" followed by "Show 85 more fields". Mouse clicking too fast for my own good. Barte (talk) 21:11, 30 May 2015 (UTC)

OK great. I just changed the name labels to "Last name 2", 3, 4 and so on to be clearer for editors. But it may take a day or two, until this new template data version is visible in VE. GermanJoe (talk) 21:38, 30 May 2015 (UTC)

That works--much clearer, indeed. Thanks. Barte (talk) 15:01, 31 May 2015 (UTC)

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36

The popups that display the Wikidata short summary of the item are great, and do an excellent job starting an understanding of a topic (not quite as good as having the first few sentences of the article with Navigation Popups); however, there is no link for editing the wikidata item, so if their is not short, you are SOL. It would be ideal, if there was room (or a link to a API tool) that allowed you to modify the summary in wikidata, when working with links.

Sadads (talk) 12:51, 27 May 2015 (UTC)

Hi Sadads,

Thanks for this feedback. Do you have a clear example of an overly long description that I can pass along to the devs, to help them understand the practical problem? Whatamidoing (WMF) (talk) 01:43, 1 June 2015 (UTC)

Sorry, I should have said "if there is not a short description". I was typing the feedback quickly during a really quick editing session.: the problem is the lack of Wikidata short descriptions on millions of items, that could fixed by editors who are deliberately linking to those items (which implies a minimal amount of contextual knowledge about the article). There were a number of links that I created in that last editing session, which didn't have Wikidata descriptions, so I couldn't confirm it was going to the right link. When popups provides those first few sentences when I hover over links in preview mode, I know for sure that the article is what I want to link to. Sorry for the slightly cknfusing feedback above, Sadads (talk) 12:18, 1 June 2015 (UTC)

I've started a task in Phabricator for your idea. Feel free to go to phab:T101056 and add any further information that you think would be helpful. Thanks again for this idea, Whatamidoing (WMF) (talk) 23:35, 1 June 2015 (UTC)

Thryduulf (talk) 10:52, 2 June 2015 (UTC)

Filed as phab:T101212. Thanks! Quiddity (WMF) (talk) 02:26, 3 June 2015 (UTC)

I'll confirm this problem exists (Mac, Chrome, both latest versions). It does seem like the sort of thing that should have been caught by QA/testing. And there is a (weird) workaround: For example, for bolded text, change it to bolded italics; now you can remove the bold (by using bolding as a toggle switch) and then remove the italics, getting this to regular text. Of course, that's not the sort of thing we want to put into a user's manual. -- John Broughton (♫♫) 02:52, 3 June 2015 (UTC)

Thryduulf (talk) 10:30, 2 June 2015 (UTC)

@Thryduulf: I found a comment in phab:T94590 saying "both underline and font [color] are blacklisted for external (non-VE to VE) pasting. They're kept when pasting from VE to VE" - so this is planned behaviour. (And I checked, that copying from VE-editmode back into VE-editmode does preserve underline). Hope that helps. Quiddity (WMF) (talk) 00:46, 3 June 2015 (UTC)

Reading that bug, it seems it's planned it isn't editable by the toolbar? It (now) is, so this seems odd. The preserving of everything except underline is very unexpected behaviour - even if underline is discouraged in articles - so it makes no sense to me to continue the behaviour. Thryduulf (talk) 07:10, 3 June 2015 (UTC)

Hi Thryduulf,

Welcome back! I haven't seen you around much recently, and I've missed you. I suppose that ArbCom's soaking up most of your time these days.

It's not actually "everything except underline". Several other things get stripped, too—just not any other things that happened to be present in that particular bit of text. (Also, context matters: section headings are supposed to be stripped if you're pasting into a basic/manual reference dialog.) I wonder whether stripping underline is the right choice. Emphasis (typography)#Overlining (and the following section in that article) indicates that different languages use different conventions. Perhaps someone like User:Amire80 could tell us whether any Wikipedias use underlining regularly or whether MediaWiki supports things like emphasis dots. Whatamidoing (WMF) (talk) 01:17, 4 June 2015 (UTC)

Not that I know. I would actually suggest to talk to Parsoid people - they may be able to analyze all the formatted text in all the languages and find whether anything is used interestingly. --Amir E. Aharoni (talk) 09:27, 4 June 2015 (UTC)

See this edit for many various damages made by VE all over the article:

• Correctly formatted paragraphs are replaced by poorly formatted ones (carriage returns in the middle of the paragraph)
• Calls to templates/références/... replaced by pure HTML
• nowiki tags added at the beginning of lines
• Titles replaced by bold text
• ...

--NicoV ^{(Talk on frwiki)} 12:04, 3 June 2015 (UTC)

NicoV, would you do me a favor and ask that new editor whether s/he copied and pasted the whole article into itself at any point (select all, copy, blank, paste)? That's what this looks like, especially the carriage returns in the middle of paragraphs. Whatamidoing (WMF) (talk) 01:39, 4 June 2015 (UTC)

Done: fr:Discussion utilisateur:Miadanamaro#Utilisation de l'éditeur visuel. --NicoV ^{(Talk on frwiki)} 04:15, 4 June 2015 (UTC)

Thanks. I really appreciate it, and I hope that we can sort out what happened. Whatamidoing (WMF) (talk) 17:25, 4 June 2015 (UTC)

Hi everyone,

I haven't seen much talk about the A/B test for VisualEditor, and I think that the experimental/bucketing phase is wrapping up within the next 24 hours. Have any of you noticed anything odd? The test is small enough that it's only affecting a small percentage of the total edits each day, but if you saw something strange and just hadn't mentioned it, then please let me know. Or, I suppose, if you haven't noticed anything very unusual while a fraction of newly registered accounts are using VisualEditor, then I suppose that's worth mentioning, too. Thanks, Whatamidoing (WMF) (talk) 01:44, 4 June 2015 (UTC)

I haven't seen any feedback on helpdesk or at the teahouse either, so I guess at least not too many people got stuck :). —TheDJ (talk • contribs) 16:25, 4 June 2015 (UTC)

To re-iterate @Whatamidoing (WMF):'s point, I’m very interested if any of you have noticed any problems that might have been overlooked by us, or which may affect the quality of the results and the conclusions we can draw. In the forthcoming analysis of A/B test data, we’re going to be looking for evidence about whether offering VisualEditor makes editing easier/more productive for newcomers, and whether it raises additional burdens (reverting damage, blocking vandals) for current editors. It’s particularly important to me that, before we start any conversations about offering VisualEditor to new users on a permanent basis, we have as much information as possible for everyone to make the best decision discussions. Jdforrester (WMF) (talk) 01:16, 5 June 2015 (UTC)

It looks like the number of nowiki tags added has gone up very slightly.

Looking through recent changes with 'nowiki+added' filter there were.

• 6 June: 31 hits (14 VE 15 Other)
• 5 June: 42 hits (17 VE 25 Other)
• 4 June: 78 hits (34 VE 44 Other)
• 3 June: 73 hits (30 VE 43 Other)
• 2 June: 64 hits (38 VE 26 Other)
• 1 June: 61 hits (42 VE 19 Other) I've excluded 66 hits by Dr Blofeld

I think this points to a slightly higher incidence of nowikis being added. The numbers are a bit low to really draw much of a conclusion. --Salix alba (talk): 09:12, 7 June 2015 (UTC)

This edit on Kid A is interesting[10] The main problem with the page is frequent references to (Kid A's lyrics) which has awkward composition of italics and an apostrophe. Manual editors and VE use a different method for rendering this:

• (Kid A's lyrics) Maunual (''Kid A''(('))s lyrics)
• (Kid A's lyrics) VE (''Kid A''<nowiki/>'s'' ''lyrics)

The manual version uses the ((')) template which includes a little extra space beforehand to adjust for the slope of italic characters. The spaceing is no so bad here but would have been worse it the album had been called Kid H causing the apostrophe to collide with the italic H.

• (Kid H's lyrics) Maunual (''Kid H''(('))s lyrics)
• (Kid H's lyrics) VE (''Kid H''<nowiki/>'s'' ''lyrics)

VE also unnecessarily puts the following space in italics which is a little annoying. Ideally we would use the template in this circumstance. It looks like there are a number of other specially designed templates for similar spacing issues. --Salix alba (talk): 08:54, 7 June 2015 (UTC)

How about we just specify a padding-right: 0.05em for <i> elements ? I think we can then kill the template and it would be much more consistently applied. —TheDJ (talk • contribs) 10:34, 7 June 2015 (UTC)

Oh, wait, this does so much more... yikes. That template is 3 characters, of which 2 are invisible... So condensed in to logic: If word == italicized and follow by a non italicized ', then insert between word and ': zerowidthjoiner (U+200D) and a hair space (U+200A). —TheDJ (talk • contribs) 10:53, 7 June 2015 (UTC)

I wonder if we could convince them to change the order that the parser handles it, so that ''' produces </i>' instead of '</i>.

Basically, VisualEditor is not going to support any local templates, including ' (because local template = template whose existence cannot be guaranteed to be present). Spaces should never be italicized. However, I can't reproduce that. Can you? Whatamidoing (WMF) (talk) 17:13, 10 June 2015 (UTC)

Thryduulf (talk) 12:34, 12 June 2015 (UTC)

When will VE stop damaging ISBN numbers ? This has been reported countless times, and it's still happening on a regular basis. Example. --NicoV ^{(Talk on frwiki)} 08:30, 12 June 2015 (UTC)

I have pinged Subbu on [11], because the latest comment on that task hints that this could be a Parsoid issue, and it is on their board for this quarter, so this task is on the radars: thanks for providing a new link though! --Elitre (WMF) (talk) 10:57, 15 June 2015 (UTC)

The result produced by VE to create tables is sometimes complex and awful for a simple table: a table inside a table, nowiki everywhere, whitespace before pipes, ... Using a proper formatting removed 1500 bytes of the previous edit that count 2700 bytes, so more than half text produced by VE was unnecessary. --NicoV ^{(Talk on frwiki)} 13:13, 12 June 2015 (UTC)

@NicoV: Thanks for the report! One note: I suspect from the class="MsoTableGrid" that the user copy-and-pasted the table from a Microsoft Word document. Considering that, I personally feel like VE did pretty well :)

Ideally, of course, we'd do even better. To make progress on this, we'd need a way to consistently reproduce the bug—ideally the document the user originally took the table from. It might be worth asking the editor to send it to us, but since they're an IP I doubt you'd hear back. Maybe you could try copy-pasting different types of tables from Word into VE and seeing if you get similar markup problems? I just tried copy-pasting the table from the version of the page with the bad markup into LibreOffice (I don't have Word) and back into VE, and the saved Wikitext was pretty good—no double table and no nowikis, although there was more whitespace than necessary.

I know this is frustrating, but if we can get one really clear reproduction, we can often fix bugs like this very quickly. Check out T98893: there had been no progress for weeks, but after I found a consistent way to reproduce it yesterday (and it was not easy), Roan Kattouw (who's amazing) uploaded a patch literally 15 minutes later. This isn't any kind of guarantee :) I'm just saying, as you probably know, that clear reproduction steps can make a huge difference.—Neil P. Quinn-WMF (talk) 05:01, 14 June 2015 (UTC)

@Neil P. Quinn-WMF: Thanks for the answer, even if I'm tired of these kind of answers.

I've always been against VE being activated by default (especially for IP and newcomers) until it has been stabilized, because users won't check what they're doing, so many damages happen on production wikis and difficult to have answers on what caused the problem. I'm happy that enwiki resorted to extreme measures to prevent that, and sad that frwiki didn't. So, no, I'm not going to spend more of my time to try reproducing the problems: WMF decided to go that way, it's their problem that it's difficult to reproduce. I already spend too much time in my opinion fixing damages done by VE and reporting problems.

Considering that fixing the problems took me a similar time than it would have required to create the table from scratch with wikitext, I really don't see how I can think of it being pretty well. --NicoV ^{(Talk on frwiki)} 11:14, 15 June 2015 (UTC)

Quick note: James F (the product manager) started a discussion over at VPPR about VisualEditor.

Dinner's calling. I'll be back in a few hours. Whatamidoing (WMF) (talk) 01:27, 18 June 2015 (UTC)

Among other problems, VE added a gallery tag with base64 junk (in the previous version, it seems there was a correct image). Other problems include poorly formatted new arguments in template (non consistent with existing arguments), poorly formatted gallery tags (put on the same line with an infobox or together), template emptied of its arguments (Palette at the end of the article), ... --NicoV ^{(Talk on frwiki)} 06:35, 17 June 2015 (UTC)

I put the wall-of-code issue at [12] (I initially thought it could be a case of broken browser plugin). Thanks, --Elitre (WMF) (talk) 04:54, 18 June 2015 (UTC)

In this edit and others on the same page, VE inserted useless p tags around paragraphs, and also p tags around useless nowiki tags. --NicoV ^{(Talk on frwiki)} 13:54, 15 June 2015 (UTC)

I didn't check in the history from which edit they were coming, but there were other problems that I fixed, including nowiki or span tags around whitespace, italic formatting around nowiki tag, ... Probably all related to VE. --NicoV ^{(Talk on frwiki)} 14:00, 15 June 2015 (UTC)

I took a look at the first revision of the article, which was not created in VE, and which already displayed nowiki and p tags issues (I'm guessing the user prepared the article elsewhere and copy/pasted it). --Elitre (WMF) (talk) 04:59, 18 June 2015 (UTC)

Quick update: I know that Aaron said last month that he was running an experiment with VisualEditor for newly registered accounts. If anyone's interested, he posted the results on Meta. Whatamidoing (WMF) (talk) 05:49, 17 June 2015 (UTC)

To summarise they looked at: activity (actual edits), productive edits (not reverted), time spent editing, short term survival (still editing after 5 days) "In no case does the test show a significant difference between conditions." The revert rate was slightly less with VE as was the block rate for damage (but not significantly so). For ease of editing there was a "Lower completion rates and more time to save" taking 18 seconds more from starting editing to saving. Overall not a great difference.--Salix alba (talk): 11:03, 18 June 2015 (UTC)

To be clear, the lower revert rate was statistically significant, but not what you might call clinically significant. The effect was real but not important.

The "lower completion rate" was balanced by opening the editors (both of them) more times. Those results are consistent with what you would expect if someone had seen one button, created an account, discovered that there were (unexpectedly) now two buttons for editing, and wanted to look at both of them before deciding which one to use. Whatamidoing (WMF) (talk) 15:02, 18 June 2015 (UTC)

In this test edit I added a wikilink to the last word of a sentence (using the tool), and then tried to continue the sentence, but the continuation also appeared bluelinked until the instant I clicked "save page", when it reformatted correctly. --99of9 (talk) 07:04, 18 June 2015 (UTC)

Hey 99of9, thanks for the report! I am not able to reproduce, so I'm wondering what you're using to edit (browser + version/operating system/Wikipedia skin)? Thanks, --Elitre (WMF) (talk) 07:15, 18 June 2015 (UTC)

@Elitre (WMF): The latest Firefox on Windows 7. Vector skin. --99of9 (talk) 07:18, 18 June 2015 (UTC)

99of9, I can see that now, I'm reporting it now. Thanks for catching it! --Elitre (WMF) (talk) 07:22, 18 June 2015 (UTC)

Thanks. --99of9 (talk) 07:28, 18 June 2015 (UTC)

It's now https://phabricator.wikimedia.org/T102919. User:Tar Lócesilion, we may have talked about something similar in the past? --Elitre (WMF) (talk) 07:33, 18 June 2015 (UTC)

Yes, Elitre, I think this was it. Tar Lócesilion (queta) 00:05, 19 June 2015 (UTC)

I'm sure that this has been reported as an issue before, and I'm sure that there is a technical reason why this is difficult to do, but really? VE is supposed to be a rough approximation of a WYSIWYG application (yes, I know that's not officially the goal, but that has lots of benefits for people doing editing), and yet, after adding a citation to an article, it isn't visible in the list of citations - the list generated by VE.

I'll try to make the problem clearer: (1) VE gets a list of citations from the article (it has to, in order to be able to offer citation re-use); (2) VE knows that the user is adding a citation (via the Cite menu); (3) VE isn't able to combine the new citation and the old citations into a single list, to be shown in the article, during the editing session; (4) VE isn't able, during the editing session, to combine the new citation and the old citations into a single list that is offered to editors when they want to re-use a citation.

I really think this qualifies as something to be added to the list of VE blockers. I was editing a couple of articles using VE, and this problem is sufficiently vexing (I can't see the citations I've added, except by clicking on each individually; I can't reuse them) to make me reluctant to use VE when I want to expand an article.

I note that the functionality that is needed does not include renumbering existing footnotes - it's fine, during an editing session, to have new footnotes simply added (number-wise and listing wise) to the end of the list of existing citations. It's fine to have the renumbering happen after the session is saved, as is the case now. The point is that new editors shouldn't have to wonder why, when they've added a citation, it doesn't show at the bottom of the article (more experienced editors have lower expectations of VE, and presumably won't be surprised), and all editors need to be able to reuse citations during the same editing session that they create them. -- John Broughton (♫♫) 21:00, 11 June 2015 (UTC)

• @John Broughton: the <references /> block is supposed to update as soon as you add a new citation. This seems like a regression (and a bad one at that). Thank you very much for reporting it! I've tracked it in Phabricator; hopefully, it will get fixed very quickly.—Neil P. Quinn-WMF (talk) 18:39, 12 June 2015 (UTC)
• John, are you talking about the Cite > Re-use list which is what "(4)" sounds like, or about the list of references at the end of the article, which is what "(3)" sounds like? Or both? And if (3), are you using ((reflist)) or <references /> Whatamidoing (WMF) (talk) 17:08, 15 June 2015 (UTC)
  • To answer your first question, I was saying that both the list of references at the end of the article, and the re-use list, were affected. Regarding your second, I was editing two articles that weren't created by me, so I don't know, off-hand, whether ((reflist)) or <references /> was used. But the vast majority of English Wikipedia articles use ((reflist)).
  • Which brings up the 800 pound gorilla in the room. Let me start by saying that https://phabricator.wikimedia.org/T102265, as it now reads, is probably WRONG. I did not say, in any way, that the articles I was editing involved <references />, and - quite frankly - I don't care about articles that use <references />, because these are a tiny minority, and likely to have few page views and few edits. What I care about is articles with ((reflist)), because - I know I'm repeating myself - that's what is used for virtually every English Wikipedia article of any significance. So I'd really like T102265 removed from the potential blockers list (or from being nominated for that); I suspect there is no regression, but even if there is, that's not the issue I want to raise.
  • The problem (and now I'm starting to have a flashback) is that it's quite possible that the position of the developers, with regard to the problems I encountered, above, is that "The English Wikipedia shouldn't use ((reflist))". Because if that is the response, it translates to this: "Even though ((reflist)) is used in the vast majority of English Wikipedia articles that actually have inline citations, we don't care. Our existing solution works fine; you just need to change the template in a million+ articles." I really hope that's not the developers' response because I firmly believe that VE should adapt to the way the world is, rather than world adjusting to the specifications that the VE developers chose to work from. And if that IS the developers' response, then I'll repeat that I'd like this issue to be nominated as a VE blocker, because it's a major, major problem. It's a major, major problem because, at the moment, the WYSIWYG aspect of VE doesn't work in the vast majority of Wikipedia articles with footnotes. And the re-use aspect of VE doesn't work in a lot, possible the vast majority, of Wikipedia articles with footnotes. Which means, basically, that these two features are not, in the real world, actually functional, even if they fully meet the specifications that the developers feel they need to meet.
  • Bottom line: There needs to be a separate Phabricator item for issues with ((reflist)); if there is not already one, I hope someone either opens one, or revises T102265 so it covers this issue, rather than the (quite possibly non-existent) issue with <references />. And I would like to see the Phabricator item regarding ((reflist)) be nominated as a VE blocker. John Broughton
    • I should note that the issue that ((reflist)) is what the entire English Wikipedia actually uses was raised a full two years ago, 1.5 years ago, when VE was first released. At the time it was explained that it was difficult for VE to use this, and that <references/> would be adapted to compensate; this appears not to have occurred sufficiently to solve the problem. - David Gerard (talk) 22:53, 15 June 2015 (UTC)
    • Tracked it down: Wikipedia:VisualEditor/Feedback/Archive_2014_1#References_list - a blank "This is one of the (many) reasons why we discourage people from using ((Reflist))." The "we" here is not specified; it's evident from actual usage (3,400,000 inclusions) that it's not any part of the editing community. This discussion from January 2014 is well worth rereading. "Staffers may wish to discourage modern editing- but the function of this beta kit is to support it." - David Gerard (talk) 22:59, 15 June 2015 (UTC)
      • I do agree with everybody here that VE should adapt to what is really used in the wiki, not the other way around. And I doubt enwiki is a special case for ((Reflist)): on frwiki, template Références (seems the equivalent of ((Reflist)), and has an interwiki link to it) reports at the top of its page that it's used on more than 390,000 pages. I also vote for this problem to be a blocker. --NicoV ^{(Talk on frwiki)} 19:18, 16 June 2015 (UTC)
        • The real root-cause fix is to make <references /> capable of at least a few of the things that ((reflist)) is. But that's been waiting 18 months. In the meantime, it may be worth special-casing a template of this difficulty and popularity - have VE treat it as a token itself rather than as a template. Perhaps with just the bare use of ((reflist)) at first, extend to parameterised cases later - David Gerard (talk) 21:37, 16 June 2015 (UTC)
• @John Broughton: sorry! It seems like I didn't fully understand the issue you were raising. The fact that ((reflist)) does not update until the page is saved is tracked at T52769, which I've updated to pass on a broad-strokes explanation about how monumentally intractable it is. I wish there was something more helpful I could say on that score, but I'm afraid not there's not.

However, T52769 does not affect the ability to reuse citations, even those created in the same session. I'm pretty sure the reuse issue you were seeing was T102265 (Citoid-created references do not appear in the re-use menu or in <references /> until after the page is saved), which I noticed while investigating what I thought you were reporting. The fix for that has been written and is going out in this week's deploy. We (the VE team) are not aware of any other issues with the reuse menu; if you are, please report them.—Neil P. Quinn-WMF (talk) 19:34, 16 June 2015 (UTC)

John, if I've read the schedule correctly (which is always a bit "^{[dubious–discuss?]}" for me  ;-) then the fix for the 'not present in the Re-use list' problem should appear here in three or four hours. If you want, you might check later today (or tomorrow) and let me know if this part is now fixed. Whatamidoing (WMF) (talk) 15:40, 18 June 2015 (UTC)

@Whatamidoing (WMF): - Thanks. After testing, I conclude that it does look like the problem - with ((reflist)) - is fixed, which is great. -- John Broughton (♫♫) 04:30, 19 June 2015 (UTC)

Is it possible to have the ability to center justify text in table cell? If not, this is my suggestion as something to add to VisualEditor. --hmich176 17:20, 21 June 2015 (UTC)

Thanks for taking the time to post here! I put your request at https://phabricator.wikimedia.org/T103276. It usually helps if a rationale/use case is provided, in these cases. Best, --Elitre (WMF) (talk) 21:20, 21 June 2015 (UTC)

User agent: Mozilla/5.0 (X11; CrOS x86_64 6946.55.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36

Sometimes you need to be able to remove the ref tags from references to create bibliographic fields that aren't used for verification (see recent changes, E.g. this diff, to Kyohei_Inukai_(b_1886)). Moreover, I am imagining adding unfootnoted references is an easy and lightweight way for experts to contribute to Wikipedia (see recommendations at Wikipedia:The_Wikipedia_Library/GLAMISTS#As "Further reading" or "Other sources" and below )

Sadads (talk) 15:59, 18 June 2015‎ (UTC)

Thanks. I've tweaked your comment to also link a specific example diff, and fixed the GLAMISTS link to a direct subsection. Hope that's ok :) I've filed it as phab:T103277. Quiddity (WMF) (talk) 21:52, 21 June 2015 (UTC)

GermanJoe (talk) 12:07, 12 June 2015 (UTC)

Just curious (and trying to prevent early archive) - could anyone else reproduce this problem with HotCat or other features? GermanJoe (talk) 13:42, 21 June 2015 (UTC)

I can (in Firefox 38/Mac 10.10, but I wouldn't be surprised if it affected everyone). I apologize for the delay; I thought this one had come up before and was trying to find the old one. But I eventually concluded that the previous problem was about the cats themselves, not about HotCat, so you get a brand-new bug number.  ;-) Whatamidoing (WMF) (talk) 23:23, 21 June 2015 (UTC)

The VE remains a vastly more feasible way to edit heavily-referenced paragraphs than wading through the computer guacamole when you just want to do some fairly simple text changes. I opened this in guacamole mode, quickly noped out to VE and it was much simpler. Cheers! - David Gerard (talk) 13:32, 21 June 2015 (UTC)

Thanks for the compliment. Whatamidoing (WMF) (talk) 23:41, 21 June 2015 (UTC)

In this edit, nowiki tags has been added in an existing reference and a whole section has been duplicated. The content of the reference was wrongly formatted (missing a pipe after the template name), but that's not a reason to add nowiki tags in meaningless places making the wikitext even worse than it was before, and to duplicate a whole paragraph. --NicoV ^{(Talk on frwiki)} 21:52, 21 June 2015 (UTC)

NicoV, the duplication might be unintentional user error (note that the heading is also duplicated but without the heading markup -- normally Parsoid-caused duplications are identical and a lot worse). As for nowiki, the problem is that when parsoid sees HTML of the form "

" where Foo is a non-existent template, strictly speaking, the nowiki protection around it is not required. But, even if we did the more complex thing (of parsing it fully and looking up whether that is a non-existent template or not), the problem is that when someone adds a new template Foo in the future, the nowiki-less wikitext will now start doing something new. So, as a general problem, we conservatively add nowiki protection whenever transclusion-like markup is seen. That said, perhaps we can be a little bit more smarter and do more work to detect when something might never parse as a transclusion, but, I am hesitant to go down that route since that is a route to code and maintenance complexity because of lots of edge cases because of potential user errors. If you might not mind me putting a spin on this, this nowiki-ing could be seen as helpful since it flagged a user error for you. Curious to hear what you think. SSastry (WMF) (talk) 21:25, 22 June 2015 (UTC)

Thanks for the answer SSastry (WMF). I've no idea about the duplication, but seems strange because the heading is duplicated without the markup which is not basic to do with an unintentional user error: normally, heading markup should be pasted also in VE, so the user had to remove also the heading markup after his first unintentional error? Concerning the wiki, I understand the reason for putting one, the template being broken, but not 2 things:

• First, why the first nowiki tags are put around more text than what's really needed? If you want to escape the opening braces, then just escape the opening braces, not from the opening braces until you reach something that is not just text. nowiki tags spanning around unnecessary long texts are not good.
• I don't understand your explanation: the previous wikitext had a given behavior (even if the displayed result is different depending on the existence of a template, it's still its behavior), so you're saying that you're changing the behavior by adding nowiki tags (display will be different than it would have been without the nowiki tag if a template is created)

--NicoV ^{(Talk on frwiki)} 21:56, 22 June 2015 (UTC)

• I'll answer your second question first (which also helps clarify for me that the duplication is very likely user error since there are no other edits in the reference). Because of the duplication, the reference changed from a non-named reference to a named reference. This marked the reference as being edited => it serialized it from scratch and that triggered the nowiki protection on the content. So, something for us to check is if we are able to narrow down the diff-range for <ref>s that we detect as changed in this case. I'm a little surprised that it marked the entire <ref> as being edited. Not sure if that is a bug in our code or an oversight. I'll test that separately. Right now, Parsoid normalizes wikitext on edits. We've refined our DOM diffing algorithm over time to narrow our diff ranges, but it can continue to be improved.
• Independent of that issue about diff-range, the other question you are asking is if our normalization is the right thing to do in this case. I think Parsoid's normalization produces a more consistent rendering, i.e. some editor might have accidentally typo-ed a transclusion, and the safe thing to do is to consistently display it as broken. Without the nowiki, if a new template is created, the rendering behavior abruptly changes (and not necessarily in ways that the original editor intended). So, yes I am arguing that given that this is an edge case, I prefer consistent behavior over surprising behavior.
• As for your first question, we should probably tweak our algorithms / heuristics some more. But, we have competing requirements of minimizing nowiki range and minimizing # of nowiki entries. The "=" sign in a transclusion markup triggers nowiking right now. So, our not-so-smart heuristic expands the range to include the "=" to avoid adding a second nowiki. Now that I said it, I can anticipate your next question about it :-) .. but yes, our heuristic doesn't know that once the (( is escaped the "=" sign doesn't always need to be escaped .. except if this error happened in a surrounding transclusion! .. so, you see how quickly this can get complex and hairy with all kinds of arcane scenarios. Our implementation strives to do the right thing in the common cases as much as possible while leaving our code maintainable. As we get bug reports about bad behavior in the common cases, we'll keep tweaking our algorithm. Does that help understand this?

SSastry (WMF) (talk) 22:28, 22 June 2015 (UTC)

Actually, losing markup on headings when you paste them into the 'wrong' spot is very common. It happens to me about half the time I copy and paste a section plus the paragraph after it. Whatamidoing (WMF) (talk) 01:32, 23 June 2015 (UTC)

In this edit, VE added empty blockquote tags. --NicoV ^{(Talk on frwiki)} 16:37, 23 June 2015 (UTC)

I tried that, and it's very trivial: try to add such a block, forgot you did it/decide you don't want or need it anymore, save, that's it :) --Elitre (WMF) (talk) 16:44, 23 June 2015 (UTC)

Well, that's not great to add invisible junk... --NicoV ^{(Talk on frwiki)} 16:47, 23 June 2015 (UTC)

I stumbled upon some <time>...</time> tags lately, here's an edit by VE where a time tag has been added. What's that? --NicoV ^{(Talk on frwiki)} 16:37, 23 June 2015 (UTC)

Hi, I found this whilst investigating: phab:T34545 ("MediaWiki should support <time> in WikiText") - that should help explain what the tag is (See also more recent tech specs at mozilla.org and w3.org). I agree the tags are not useful in the context of that edit though... Ok, I tried copy and pasting the text from the mozilla.org link, using VE in this diff and it did include the tags, so that's probably why it was included in the example you linked. I've filed phab:T103723 to track/discuss this. Quiddity (WMF) (talk) 17:54, 24 June 2015 (UTC)

In some cases, VE adds nowiki tags just to wrap them inside an italics or bold formatting, like here or here. --NicoV ^{(Talk on frwiki)} 05:35, 25 June 2015 (UTC)

I'll add the URLs to mw:Talk:Parsoid/Normalizations. The Parsoid team would be very grateful to get examples of issues with nowiki tags there. Thank you! --Elitre (WMF) (talk) 18:05, 25 June 2015 (UTC)

Examples are easy to find on frwiki: list of edits with nowiki. --NicoV ^{(Talk on frwiki)} 18:26, 25 June 2015 (UTC)

User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0

I was trying to update this page and had trouble adding new entries where cell contents were centered. perhaps this feature is there, but I cant find it.

https://en.wikipedia.org/w/index.php?title=List_of_Institute_Professors_at_the_Massachusetts_Institute_of_Technology&veaction=edit

Dalek2point3 (talk) 17:46, 29 June 2015 (UTC)

Hi Dalek2point3, thanks for your suggestion. Centering (alone) can't be done inside VisualEditor right now. It's on the list for future improvements to table editing. I'm not really sure how soon that will happen. I believe that the team would like to re-design the menus and controls for table editing before adding any new items to those menus.

However, if you're trying to center the first "header" row, then that is possible. Put your cursor inside the new header cell, and change the "paragraph style" (in the main toolbar, on the left) from "Content cell" to "Header cell". Whatamidoing (WMF) (talk) 18:05, 29 June 2015 (UTC)

Thanks Whatamidoing (WMF)! I'm glad it wasnt just me being bone-headed :) I did manage to center the content using the regular code, so it worked out okay. Btw, I hadnt used VisualEditor in a while, its really coming along and I so prefer it to the classic editor! Yay. — Preceding unsigned comment added by Dalek2point3 (talk • contribs) 18:26, 29 June 2015 (UTC)

Wikipedia:Keyboard shortcuts says: "v Edit with VisualEditor (if available)." In current Firefox and Chrome versions Alt+⇧ Shift+v opens VE when I'm logged in with VE enabled at Beta (Special:Preferences#mw-prefsection-betafeatures), but not when VE is disabled at Beta or I'm logged out. Tested on Example and other articles. Other shortcuts like Alt+⇧ Shift+e (source editor) works both logged in and out. VE can be started manually with veaction=edit whether I'm logged out or in with VE enabled or disabled at Beta. I examined a report at Wikipedia:Teahouse/Questions#Visual Editor and don't know whether this behaviour is normal. PrimeHunter (talk) 13:16, 30 June 2015 (UTC)

When you are not in the beta, there are no tabs, and thus no links to the editor to bind the hotkey to. —TheDJ (talk • contribs) 18:32, 30 June 2015 (UTC)

Thanks for the explanation. I didn't know it must be tied to a link. PrimeHunter (talk) 01:47, 1 July 2015 (UTC)

Lam-ang (talk) 17:05, 30 June 2015 (UTC)

Reproduceable with Windows XP, FF 38, vector skin and Aruba. Blue progress bar fills up completely, but isn't removed then - edit window in the background is completely generated, but is staying disabled/blocked. GermanJoe (talk) 17:32, 30 June 2015 (UTC)

Filed as phab:T104377. Thanks both. Quiddity (WMF) (talk) 19:32, 30 June 2015 (UTC)

Marked as resolved now. Are we waiting for the patch to be deployed here? — Martin (MSGJ · talk) 10:30, 2 July 2015 (UTC)

I just tried this and it still doesn't open for me. --99of9 (talk) 05:19, 3 July 2015 (UTC)

It was merged into the 1.26wmf13 branch, and that version will go live next week (so, at Wikipedias: next Thursday, July 9). Quiddity (WMF) (talk) 20:03, 3 July 2015 (UTC)

Backported into 1.26wmf12 (gerrit:222743), thanks to everyone who worked on this.--Lam-ang (talk) 14:40, 4 July 2015 (UTC)

In enwiki I see "Edit source" on the left and "Edit" on the right. On enwikinews they are in the other order, so out of habit I clicked the wrong one. --99of9 (talk) 05:24, 3 July 2015 (UTC)

Bugs me as well. Moreover, this is the story for Wikiquote as well.
117.217.116.191 (talk) 06:26, 4 July 2015 (UTC)

Hi 99of9, User:117.217.116.191. You are correct, there's inconsistency there, and having to work on several different Wikipedias, I feel your pain... The en.wiki community made a decision a couple of years ago, which means that the order of the tabs here is different from that on the other 200+ Wikipedias where VE is in opt-out state (not to mention hundreds of other WMF wikis where it's still a Beta Feature). The reason why the default configuration has VisualEditor as the first tab and the wikitext editor as the second one instead is that the editing option which feels more familiar to new editors (i.e., the one that is similar to the e-mail or word-processing programs they have used for years) should be slightly more prominent. Recent research shows that new editors try both and then go with the one they want, anyway. From recent related discussions, it looks like some community members still believe that en.wiki's order is the one to maintain. --Elitre (WMF) (talk) 18:35, 6 July 2015 (UTC)

Harold Innis won't finish VE-loading for me in Firefox 39.0 or Chrome 43.0.2357.81 Riggr Mortis (talk) 16:58, 6 July 2015 (UTC)

Riggr Mortis, would you please try it again? It opens for me in Firefox, and Ops has been having some problems with the servers. Whatamidoing (WMF) (talk) 18:40, 6 July 2015 (UTC)

I enjoy the new linking system in the VisualEditor, however, there appears to be no function to delete an already-done link.

In this case, when one clicks on the link button to a word (if s/he has already highlighted the selected words), then one sees the link options pop up. Then one types in an alternate link other than the selected words, for example, a link of "execute" linking to "execution by firing squad". But if one wants to unlink, s/he would have to highlight the link, delete the whole link and write down the word again.

It feels rather tiring to do that, and so probably add a button in the link options where you could easily unlink the link without having to do the long process. Qwertyxp2000 (talk | contribs) 06:52, 4 July 2015 (UTC)

You need to select the link, open the linking tool, and click the red "Remove" button in the lower left corner. I'm looking at updates to the user guide, and perhaps this could be made a little clearer there. Whatamidoing (WMF) (talk) 18:33, 6 July 2015 (UTC)

You could also use the 'Clear styling' tool in the format dropdown (CTRL+M or CTRL+\ on PC). ESanders (WMF) (talk) 14:18, 7 July 2015 (UTC)

Kerry (talk) 05:22, 30 June 2015 (UTC)

Hi Kerry, could you let us know what browser (incl. version), and what operating system, you're using? Thanks. :) Quiddity (WMF) (talk) 19:11, 30 June 2015 (UTC)

Supplied, but it seems to be working now. Kerry (talk) 23:19, 30 June 2015 (UTC)

It's not that I have a problem; I can always use the source editor, but I run classes that teach people how to edit Wikipedia. These folk do struggle with the markup so I'd like to teach the VE instead, but with them in the class situation, when something goes wrong (like this situation of the VE not opening properly), there isn't the option of switching over to the source editor in the classroom situation. At the moment, this is the biggest problem with VE, you can't be VE-only even for a new user. You still need source editor skills as a backup for what you can't do in the VE. And I have no idea what's going to happen with Talk pages if someone reverts their edit (a common new user experience) and tells them to discuss it on the talk page. Is there any info out there on priorities on these things so we can see when we can seriously consider teaching VE? Kerry (talk) 23:28, 30 June 2015 (UTC)

Hi Kerry, I can open this on my Mac in Firefox 38 and Safari 8. I'll ask someone with Chrome to try it out. It looks like you were able to make an edit on that page in VisualEditor just a few minutes later. When you were having problems, did you happen to try opening any other page in VisualEditor?

The research done recently on offering new editors VisualEditor and wikitext vs wikitext alone didn't find any difference in the likelihood of using talk pages. Whatamidoing (WMF) (talk) 17:33, 2 July 2015 (UTC)

I made a number of attempts to open it with the VE that failed. Later, yes, as I said, it worked. I did not try to open other articles as there was only one article I was interested in editing at that time and so I switched to source editor to do it. I note that a few of the bug reports below appear to be describing exactly the same problem. Can you point me to the research you mention please. Kerry (talk) 05:07, 3 July 2015 (UTC)

Hello, Kerry. I experienced a similar issue recently, and found out that this is due to general issues with the site that Ops are fixing (similar to https://wikitech.wikimedia.org/wiki/Incident_documentation/20150702-RESTBase, or https://phabricator.wikimedia.org/T104376), so it's not a VE-specific problem. As for the recent research about VisualEditor, see m:Research:VisualEditor's effect on newly registered editors/May 2015 study. Information about talk page use is in the work logs at the top of m:Research talk:VisualEditor's effect on newly registered editors. HTH, and thanks for stopping by! --Elitre (WMF) (talk) 09:14, 4 July 2015 (UTC)

I am experiencing the same problem again this evening - could not open VE on the article Country Women's Association despite a number of attempts. So I started clicking a link at random to go to another article and tried the VE on that - failed again, clicked more random links and every time the VE is failing. I don't appear to be able to open any article in the VE at the moment. I also notice that I see the VE loading-progress bar appear, fill across to the right, disappear very briefly, reappear and then fill across to the right and then disappear and I am dumped back in normal read mode. I am definitely seeing the progress bar do its thing twice. No problem opening source editor though (tested it on articles I could not open in VE). Kerry (talk) 12:49, 4 July 2015 (UTC)

OK, some minutes later, now the VE is working again (opens any article I ask it to including some I tested before). No idea why it changed. I did not close my browser or anything like that. Kerry (talk) 13:17, 4 July 2015 (UTC)

That sounds exactly like the server problem. It started a couple of weeks ago and is creating some sleepless nights for the Operations team. It's actually affecting everything, only it's more noticeable in VisualEditor ("because Javascript", I've been told). Whatamidoing (WMF) (talk) 04:20, 9 July 2015 (UTC)

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0

Clicking on the text after double-clicking the cell selects everything, making it impossible to move the text cursor with the mouse.

HoboMcJoe (talk) 14:34, 6 July 2015 (UTC)

Hi HoboMcJoe,

When you say that it selects "everything", do you mean that it selects the whole page, the whole table, or the whole cell? Also, would you try something else? Click the cell's contents. (It should select the whole cell.) Then, instead of double-clicking, press Return. That should put your cursor inside the cell (at the end of the text). There's a table with lots of text at the end of User:Whatamidoing (WMF)/sandbox right now, if you want to test there. (It's just a sandbox, so feel free to change anything and save edits if you want.) Whatamidoing (WMF) (talk) 18:43, 6 July 2015 (UTC)

Sorry I wasn't clear. It selects the whole table, including the headings. I still have the same problem after trying that option, with the cursor at the end of the text, but with clicking inside the cell to move the cursor selecting the whole table. It seems to be specific to Firefox. HoboMcJoe (talk) 20:51, 6 July 2015 (UTC)

I can't reproduce this in Firefox 38 on Mac OS 10.10. Which article were you working on? Or does it happen in every article? Whatamidoing (WMF) (talk) 21:47, 8 July 2015 (UTC)

This looks like https://phabricator.wikimedia.org/T103035. ESanders (WMF) (talk) 11:12, 10 July 2015 (UTC)

Thryduulf (talk) 22:25, 9 July 2015 (UTC)

I've reported this myself on Phabricator as I think it's a high priority to fix, and reproduced it (without saving) on it.wp. Thryduulf (talk) 22:46, 9 July 2015 (UTC)

Eewww, and thanks. Whatamidoing (WMF) (talk) 01:58, 10 July 2015 (UTC)

Hi Thryduulf,

Just a quick update to say that the team fixed that today and made an emergency deployment, so it should be gone now (except from any stale caches). They send their thanks and appreciation for the clear bug report. Whatamidoing (WMF) (talk) 01:43, 11 July 2015 (UTC)

Kerry (talk) 21:42, 6 July 2015 (UTC)

Did any of your edits involve pasting a ref from another page into this one? Whatamidoing (WMF) (talk) 21:45, 8 July 2015 (UTC)

Fortunately it's a very new article with very few edits so this is the diff for that edit (flagged as "VE" and "switched") and does not show any citations added, therefore there is no possibility I pasted references from another page (I do paste references in the VE, but not it seems in this case). Kerry (talk) 09:00, 9 July 2015 (UTC)

Given that you successfully switched from VE -> source editing, I am fairly certain this inability to save is because of transient backend server issues (restbase) during this time. SSastry (WMF) (talk) 17:52, 9 July 2015 (UTC)

Scuttlebutt says that the problem has been found, and that this will be fixed when the devs are back in the office (in about 36 hours). Whatamidoing (WMF) (talk) 06:51, 12 July 2015 (UTC)

117.212.136.169 (talk) 06:32, 1 July 2015 (UTC)

I also had problems with Global Positioning System today. The loading bar got up to about 75% and then it froze. — Martin (MSGJ · talk) 10:28, 2 July 2015 (UTC)

I believe that will be fixed (here) with next Thursday's update. Whatamidoing (WMF) (talk) 17:48, 2 July 2015 (UTC)

Not sure if it's a related problem but Jeremy Bascom is behaving very strangely. It wouldn't open with VE, and now it won't save. (Since then I've had a similar problem with Bobby Lea, but no problem in my sandbox.) Red Fiona (talk) 21:25, 5 July 2015 (UTC)

I'm thinking that this is the server crisis, rather than the link-based problem above. They're working on it, but it seems to be one of those problems that takes forever to find the bug (and then might take only minutes to fix). I appreciate your patience with this situation. Whatamidoing (WMF) (talk) 04:22, 9 July 2015 (UTC)

No worries. It certainly sounds more like the problem SSastry (WMF) is describing further down the page. It's still happening on a couple of pages, a Parsoid 500 error message is what comes up on first save attempt if that helps.Red Fiona (talk) 00:21, 10 July 2015 (UTC)

Quick update: The save problem is supposed to be fixed on Monday morning (PDT), and the general server flakiness about opening is supposed to be fixed already. Whatamidoing (WMF) (talk) 06:53, 12 July 2015 (UTC)

Clicking on "Cite" in VE (the text, not the arrow) just opens the normal list of citations, not the interface to generate a citation via URL. I am almost 100% sure, I used that tool just 12 hours ago with no problems (Windows XP, vector, FF 39.0). Just in case: If Visual Editor is checking Citoid's availability and disables the function accordingly, it should display a short message like "Citoid unavailable. Please use manual citation selection." for clarity. GermanJoe (talk) 12:21, 7 July 2015 (UTC)

Thanks for the report. This was not deliberate, and we are investigating. ESanders (WMF) (talk) 14:12, 7 July 2015 (UTC)

@ESanders (WMF): Looks like the purge re-activated the function, thanks (still a weird glitch). 2 minor points remain though:

• The arrow next to "Cite" to directly select citations from a dropdown list has vanished (but maybe that was an intentional design decision?).
• Closing the "Cite"-window stores the window setup with the last active sub-window, either "Automatic", "Manual" or "Re-use" (nice feature). However, closing "Cite"-window in "Manual" or "Re-use" mode and re-opening the "Cite"-window, the "Cancel" button is missing (it's only shown after closing and re-opening in "Automatic" mode). It should be visible opening the Cite-window in all 3 modes. GermanJoe (talk) 14:45, 7 July 2015 (UTC)

There have been a lot of weird glitches recently, affecting everything. The servers have unfortunately not been in their usual robust health for the last couple of weeks.

About the arrow next to "Cite": Can you give me a screenshot? Are you talking about the button in the main toolbar, which ought to look like File:VisualEditor citoid Cite button.png but which could look like File:VisualEditor - Cite Pulldown.png if Citoid is missing/not installed? Whatamidoing (WMF) (talk) 21:52, 8 July 2015 (UTC)

Yes, the button looked like the second image (but as I said, maybe that was the old temporary design - no big deal, if it's gone for good). GermanJoe (talk) 07:30, 9 July 2015 (UTC)

GermanJoe, was this at en.wp? Do you have your language set to plain-vanilla "en" in Special:Preferences? They're trying to track down a particularly elusive bug that sometimes causes this problem. Whatamidoing (WMF) (talk) 01:57, 10 July 2015 (UTC)

It was at en-Wiki with language setting in preferences to plain "en - English". GermanJoe (talk) 10:55, 10 July 2015 (UTC)

I'm not sure that it's the same one, then, (so far I've only seen it at non-en Wikipedias with the language set to "en"), but: User:Mvolz and User:Krinkle, could this be another instance of phab:T93800? Whatamidoing (WMF) (talk) 06:49, 12 July 2015 (UTC)

Yes User:Whatamidoing (WMF), it turned out to be the same issue. The issue is that sometimes the configuration page for citoid mysteriously disappears from the cache for a particular language; it is random whether it is the site language or another language. In this case it was en on en wiki, which obviously impacted a lot of people. The previous times it was for the non-main language of the wiki so it impacted fewer people. Please keep reporting these kinds of outages on the phabricator page as we still don't know what's causing the issue :(. Mvolz (WMF) (talk) 07:18, 12 July 2015 (UTC)

Mvolz (WMF), what would be the most useful information for you? Page/article name? Exact time? GermanJoe's pretty awesome about getting clear and reliable feedback to us, so if there is something you want to know, he might be able to keep an eye out, just in case he encounters this rare bug again. Whatamidoing (WMF) (talk) 21:42, 12 July 2015 (UTC)

When will VE stop adding unnecessary span tags around whitespace characters ? --NicoV ^{(Talk on frwiki)} 07:06, 18 July 2015 (UTC)

Other example. Given the fact that VE has recurrent problems with handling the whitespace character before a colon, don't you have tests for this before releasing VE on production wikis ? --NicoV ^{(Talk on frwiki)} 20:49, 19 July 2015 (UTC)

Third example and fourth example, including also list made with HTML syntax. Other example --NicoV ^{(Talk on frwiki)} 05:54, 20 July 2015 (UTC)

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.134 Safari/537.36

it should look like [1] I look on the editor, I found a list references, when I click on it copy a lot of references. No way to place a single ref? (

Nestashi (talk) 09:09, 15 July 2015 (UTC)

Hi Nestashi, you should be able to add a citation by placing your cursor at the end of the sentence, and then clicking the "Cite" button. Choose the type you want (a new automatic one, a new one that you fill out by hand, or to re-use an existing one) and then insert it. Whatamidoing (WMF) (talk) 17:03, 22 July 2015 (UTC)

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	To cite a source using ((Sfn))
Steps to Reproduce:	#Add info Click on "insert" and then on "template" Search for and select Sfn Fill in parameters Click on "insert"
Results:	A footnote and reflist was created.
Expectations:	Just a footnote
Page where the issue occurs	https://en.wikipedia.org/w/index.php?title=List_of_streets_in_the_1st_arrondissement_of_Paris
Web browser	Google Chrome Version 43.0.2357.134 m
Operating system	Windows 7
Skin	Vector
Notes:	Screenshot:
Workaround or suggested solution	It appears the problem is only limited to appearance in the VE. When you save your edit, the problem has no ill effects on the end result. - Presidentman talk · contribs (Talkback) 12:49, 21 July 2015 (UTC)

Presidentman talk · contribs (Talkback) 20:44, 18 July 2015 (UTC)

Hi Presidentman,

That's a very interesting situation. It turns out that it happens to far more templates (anything containing ref tags) and also galleries. I've filed a report about it, but it might be that this is intentional. Whatamidoing (WMF) (talk) 18:53, 22 July 2015 (UTC)

-- ferret (talk) 13:31, 17 July 2015 (UTC)

I may have other issues here. I have just completed this set of edits to clean up weird markup that VE used when I was copy and pasting cells, i.e. copying and pasting the first cell that contained a "Game engine" wikilink to the next. Seems like copy and paste didn't work too well. Unfortunately cleaning this up doesn't seem to have had any affect on the "insert row" problem with this table. I'll continue looking for oddities with the table... just not much of a table expert. -- ferret (talk) 13:43, 17 July 2015 (UTC)

A small update. This table (before I ever touched it) was using Template:Rh on the first cell of each row. Removing this styling caused Insert Row to stop making all new cells "Header" cells. However it still only inserted 8 cells.. Will continue trying to find what's troubling VE with this table. -- ferret (talk) 13:57, 17 July 2015 (UTC)

Ok, I think I've figured it out. Template:Yes and Template:No are causing it. See this diff. Inserting a row on the first three tables that had a variation of Yes and No will result in the "too few cells" issue. Inserting a row in the fourth table, without Yes and No templates, works as expected. Edit: Template:Partial too. -- ferret (talk) 14:32, 17 July 2015 (UTC)

I'm glad that you figured it out, and doubly glad that you posted the solution. (Those templates are very odd; it looks like they're exploiting a bug in the parser to both be table cells and not be table cells.) Whatamidoing (WMF) (talk) 17:50, 22 July 2015 (UTC)

I suspect that whole family of templates is affected. Template:Rh on the first cell caused all new cells to be "header" type, while the "coloration" templates caused too few cells to be generated. -- ferret (talk) 19:03, 22 July 2015 (UTC)

In wiki-editor, when you add references to an article that doesn't contain a reflist or /references, a red warning note is placed on the end of page. Could something similar be done with VE?

Last time I raised this issue I was told it didn't matter because a bot would come along and add the reference list later. Unfortunately, that relies on the bots coming along. For example, I edited Dorian Mortelette 9 days ago, and no bot has yet been past to add a reference list. (This is not a diss on the bots, the bots do excellent work.) Meanwhile Dilshod Mansurov, which I edited 7 days ago, has been visited by a bot to append a reference list.

Adding a reflist or /references is really easy, but also easy to forget to do, particularly with stub articles.Red Fiona (talk) 16:46, 19 July 2015 (UTC)

+1. Did someone seriously say that a piece of the MediaWiki software didn't matter because of en:wp bots? - David Gerard (talk) 19:07, 19 July 2015 (UTC)

They didn't, I mis-rememberd (terrible sorry to the person I mis-quoted, this is why diffs are my friend https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=next&oldid=622825973)Red Fiona (talk) 19:37, 19 July 2015 (UTC)

There is no red warning note at the end of the page, no matter which editor was last used to edit it. Now (since March) MediaWiki just displays the refs at the end of the page instead of displaying the red warning note at the end of the page. The behavior is the same for VisualEditor and the wikitext editor. Whatamidoing (WMF) (talk) 19:06, 22 July 2015 (UTC)

Red Fiona (talk) 00:41, 17 July 2015 (UTC)

Hi Red Fiona,

This one baffles me. I thought it sounded familiar, but the last sentence in the diff isn't the last thing on the page – it's just the last thing before the references section. That means that it's not the old bug that I was remembering. Have you encountered this again? Whatamidoing (WMF) (talk) 17:21, 22 July 2015 (UTC)

Not had a repeat. I was wondering if I'd confused the program somehow by removing something that wasn't visible.Red Fiona (talk) 20:43, 22 July 2015 (UTC)

I'm using the latest Firefox on Windows. Go to e.g. Ionic compound and scroll down until the section title "Bonding" is at the top of your window. Then click "edit" (just next to the section title). VE opens, but has scrolled to some other location so now "Bonding" is about half way down my page (BAD). Next you click in the "Bonding" section (where you alway wanted to edit) and it repositions the page so Bonding is now at the top (GOOD but it should have always been there).

Or try this, again scroll down, click "edit" on the Bonding section, observe the bad scroll position. Now change tab on Firefox and then change back. Now the Bonding section has conveniently relocated itself to the top where it should have been in the first place.--99of9 (talk) 07:39, 17 July 2015 (UTC)

I can reproduce this in Firefox but not Safari, so it's probably Firefox-specific.

I couldn't find an open bug for this, so I've created a new one. I wouldn't be surprised if it gets merged into an older one. Whatamidoing (WMF) (talk) 17:47, 22 July 2015 (UTC)

Thanks. --99of9 (talk) 06:56, 23 July 2015 (UTC)

In this edit, VE apparently added useless wiki tags around a whole sentence simply because there were 2 (entirely separate) single quotes in it. --NicoV ^{(Talk on frwiki)} 22:00, 26 July 2015 (UTC)

In this edit, VE apparently added a useless nowiki after a template, in an otherwise unmodified sentence :

• The nowiki is useless
• VE shouldn't modify by itself sentences that are not modified by the user

--NicoV ^{(Talk on frwiki)} 09:30, 27 July 2015 (UTC)

See this edit. Can VE be fixed to stop producing such unnecessary complex and ugly formatting? --NicoV ^{(Talk on frwiki)} 21:00, 19 July 2015 (UTC)

Well... to be honest, I'm not sure. How different is your question from "Is it possible to get editors at the French Wikipedia to stop formatting tables in Microsoft Office and then pasting them into articles?" Whatamidoing (WMF) (talk) 19:12, 22 July 2015 (UTC)

Let's see... For example, I highly doubt that nowiki tags were added in Microsoft Office: it's only VE that's adding nowiki tags with carriage returns. It's only VE that's deciding how to convert a Microsoft Office table into wiki text... --NicoV ^{(Talk on frwiki)} 19:16, 22 July 2015 (UTC)

The table being copied out of Microsoft Office has a plain space at the start of each cell. That space is generated by Microsoft, not by VisualEditor. To keep the space that the user added, the nowiki tags are necessary. As far as I can tell, the realistic options are:

1. break VisualEditor so that editors cannot do things in VisualEditor that they are allowed to do in wikitext (e.g., adding a space or blank line at the start of a table cell),
2. live with the fact that this editor pasted a table that contains a space at the start of each cell (and possibly engage in educational efforts to discourage it), or
3. ask Microsoft to prevent its users from abusing spaces as table formatting devices.

The third option probably looks a lot like the second in practice. Unfortunately, the devs have historically been quite opposed to requests that I make which amount to "magically know whether the editor wanted that space, and keep or remove it based on that magical knowledge". If you can make a plausible case for deliberately refusing to let VisualEditor do everything that the wikitext editor can do, then I'm certainly willing to file the request. Whatamidoing (WMF) (talk) 20:24, 22 July 2015 (UTC)

You seem to discard every option where VE would be smart: space at the start of a cell are simply discarded in the rendering by MediaWiki. Try removing the nowiki tags and the space between them in the example I linked at the beginning: the rendering is exactly the same with or without them. So why VE could not be smart and simply remove them? Why always trying to report VE problems on other things?

There's nothing magic in my request: removing the nowiki tags with the space between them gives exactly the same visual result as adding them. Using a clean syntax wouldn't change anything for people using VE, it would just stop producing ugly and unnecessary complex wikitext. --NicoV ^{(Talk on frwiki)} 20:47, 22 July 2015 (UTC)

In the wikitext editor, a person can choose to deliberately add a single space surrounded by nowiki tags. You are proposing that in VisualEditor, that person be technologically prohibited from doing that. Even if you actually want "space contents" in the cell, and even if you would choose to add "space contents" using nowiki tags in the wikitext editor, then VisualEditor will only permit "contents" and will throw away the space that you deliberately added. If that's what you want, then all I really need from you is a clear statement that you really do want VisualEditor to be incapable of doing things that wikitext supports. Whatamidoing (WMF) (talk) 21:24, 22 July 2015 (UTC)

You're really twisting things: at no point the user wanted the current result (either he wanted a visible space at the beginning which he didn't get, or he didn't want it and there was no reason for this space with nowiki), so why creating a convoluted syntax for something the user never wanted? And, well, if it means that VE is prevented from doing completely silly things, that are just complex syntax without any visible result in the produced article: YES, I really do want VisualEditor to be incapable of doing those things. Extra space at the beginning of a cell is not producing any visible difference in the result, so either VE produce a result without that silly syntax or, if you believe that the user wanted a visible space at the beginning of the cell, produce a result with actually that visible space. --NicoV ^{(Talk on frwiki)} 21:48, 22 July 2015 (UTC)

Thank you for being explicit. As you know from following this board for a long time, we also receive complaints that VisualEditor prevents editors from doing things that they can do in the wikitext editor. I've mentioned you in the request on Phab, so it should turn up in your list there. Whatamidoing (WMF) (talk) 19:43, 27 July 2015 (UTC)

Could VE be smart enough to properly handle links to other wikis, by using a clean syntax [[:xx:link|text]], rather than creating external links like in this edit? --NicoV ^{(Talk on frwiki)} 21:05, 19 July 2015 (UTC)

I can't reproduce this. Can you? Whatamidoing (WMF) (talk) 20:16, 22 July 2015 (UTC)

I don't know, I have completely stopped using VE. But, it's not a single case: Hélène Perdriat. --NicoV ^{(Talk on frwiki)} 20:55, 22 July 2015 (UTC)

Have you seen any that are correct? Whatamidoing (WMF) (talk) 19:48, 27 July 2015 (UTC)

Whatamidoing (WMF) I don't know, because I'm finding them trough Check Wiki error #91 which lists external links to other wikis. --NicoV ^{(Talk on frwiki)} 20:10, 27 July 2015 (UTC)

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36

I wish this had a way to type in changes that you're making as your'e making them, so you don't have to remember them as you go along. If it already exists, sorry! It's not intuitive/visible!

Kitty4777 (talk) 21:43, 27 July 2015 (UTC)

It's possible in two ways but whether it's intuitive is a separate question.

1. Make some change, click on Save, write your edit summary in the box, click Resume Editing, make some other change, click on Save, write your edit summary in the box, click Resume Editing, and repeat until ready to finally Save.
2. Make all your changes, click Save, then click Review Your Changes to be reminded of what you did, write your edit summary, then Save

The second method shows a diff which is expressed in markup, which may be quite confusing to VE users as it will not look like what they saw. Kerry (talk) 21:59, 27 July 2015 (UTC)

It seems you cannot do a WP:NULLEDIT with the Visual Editor. That is, open in the VE and then SAVE without changes or edit summary in order to purge the page. You are forced to do a Dummy edit (e.g. add a space at the end of a para) and add an edit summary. When you are working on a set of articles, it's frustrating to be seeing redlinks for want of a purge. Kerry (talk) 00:30, 22 July 2015 (UTC)

Null edits aren't really supported in the Wikitext editor, either. You must specifically click a "purge" button to purge. — Arthur Rubin (talk) 00:54, 22 July 2015 (UTC)

Null edits seems to work for me in the markup editor. And where is this purge button (I cannot see one on my screen)? Kerry (talk) 01:38, 22 July 2015 (UTC)

Purge button requires enabling a gadget in Preferences. -- ferret (talk) 01:40, 22 July 2015 (UTC)

I have enabled it but still cannot see any purge button in either the source editor or the VE? Where on screen should I expect to see it? It says "top of the page" but I cannot see anything new or "purge" related? Kerry (talk) 08:11, 22 July 2015 (UTC)

On Vector, it will appear at the top, under the "More" submenu. -- ferret (talk) 11:48, 22 July 2015 (UTC)

Null edits are not (currently) possible in VisualEditor. Also, "purge" and "null edit" are not synonyms. Null edits are accomplished by opening the wikitext editor and saving with no change and no edit summary. Purging is accomplished by adding action=purge to the URL (or installing a gadget that will let you click a link to re-write the URL). Whatamidoing (WMF) (talk) 19:13, 22 July 2015 (UTC)

In case anyone is interested in why you would want to do a null edit, this is one method to get changes to a template to appear in an article as it effectively fetches for transclusion the edited version of the template ... at least this is the primary reason why I have done null edits in the past. --User:Ceyockey (talk to me) 22:38, 27 July 2015 (UTC)

I was trying to add some content to the end of the Martin Love article. I went to the bottom of the article and couldn't seem to be able to get a text cursor to appear (clicking there didn't seem to work, possibly because of the presence of a template?) but then the VE suddenly offered up "+ Insert paragraph" so I clicked that and added my content (which was a cut-and-paste of some existing content as I was reordering the sections). Everything looked OK on screen and I saved it. I then opened it in the source editor and found that the cut-and-paste material had been placed under the Categories. See the diff. I don't know if it matters where the categories appear within the article, but I think it's going to enrage the source editors if VE users start "putting" the categories into the middle of the article as it is evidently possible to do when you add content at the end of the article, noting that the source editors will probably assume that the VE users did it deliberately/carelessly as they will be unaware that VE users manipulate the categories in an entirely different way. Kerry (talk) 21:41, 27 July 2015 (UTC)

Hi Kerry. I think it was supposed to be fixed for quite some time, probably another regression of VE... I created the task in phabricator for this. --NicoV ^{(Talk on frwiki)} 07:03, 28 July 2015 (UTC)

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	I was trying at use VisualEditor to modify several infoboxes.
Steps to Reproduce:	I clicked "Add more information," searched for a field which returned results, and clicked on the field. The field is highlighted but does not add to the list like it should. This is the case for any fields I try to add.
Results:	I tried to reproduce this on several different articles, with several different infobox types, with several different browsers, and by clicking on several different fields.
Expectations:	The field clicked on would add to the list as per usual.
Page where the issue occurs	(Presumably) all articles in addition to user sandbox
Web browser	Chrome version 44.0.2403.89
Operating system	Mac OS X 10.10.4
Skin	Vector
Notes:	I tried doing this by traditional editing and there was no problem.
Workaround or suggested solution

Ergo Sum (talk) 19:29, 24 July 2015 (UTC)

It is also not possible to add parameters to a newly added template. I'm seeing this in Firefox 39 and Chromium 3.0.2357.130 on XUbuntu 14.04. I'll report it in Pharbicator now if nobody has beaten me to it.Thryduulf (talk) 19:34, 24 July 2015 (UTC)

Now reported as Phabricator:T106885. Thryduulf (talk) 19:43, 24 July 2015 (UTC)

Thank you, Thryduulf.

Ergo Sum, can you give me a diff? I need to know whether you had added the infobox during that edit, or if you were changing an infobox that was present before you started working on the page. Whatamidoing (WMF) (talk) 19:54, 27 July 2015 (UTC)

Whatamidoing (WMF), the anomaly occurred during both events. Initially, I tried to edit a preexisting infobox to no avail. I then tried to create a new infobox in my user sandbox and experienced the same problem. I thought I should note that after a few days of experiencing this, the issue is apparently resolved. Sadly, I cannot say that I had anything to do with this resolution (at least not intentionally). Thanks for your attention. Ergo Sum (talk) 22:21, 27 July 2015 (UTC)

Hi Ergo Sum,

Thanks for that clarification. The bug for not being able to add one for a new infobox has been fixed. I'm not sure if the other (adding parameters to a pre-existing infobox) was part of that. If it turns up again, would you please let me know? I'd really appreciate it. Whatamidoing (WMF) (talk) 17:14, 28 July 2015 (UTC)

Will do. Thanks for the help. Ergo Sum (talk) 18:18, 28 July 2015 (UTC)

That request has probably already been filed (Phabricator's search feature is horrible for casual users, just saying): Having created an automatic citation via Citoid, it would be a lot more convenient to allow an immediate edit of the result. Suggestion: add a second "Insert and edit" button in the upper right window that performs the "Insert" and immediately open the correct type of "Edit" window for the created object. GermanJoe (talk) 13:54, 23 July 2015 (UTC)

I think it's a great idea. The team has talked about this before (it's all pending Design Research's views), but I don't think they had put it in Phabricator yet, so I've added it. Whatamidoing (WMF) (talk) 19:52, 27 July 2015 (UTC)

@Whatamidoing (WMF): Has been speedy-declined for some strange reasons. "Edit" is currently not immediately available in the so-called "successful workflow" (just checked to be sure). Users need to close and re-enter the window, before they can edit. No idea, what Jdforrester-WMF is referring to, certainly not the current situation. Is it allowed/possible to re-open a task for clarification? GermanJoe (talk) 21:00, 27 July 2015 (UTC)

Never mind, I saw your comment and added a few more thoughts. GermanJoe (talk) 15:08, 28 July 2015 (UTC)

Right now, the flow, once an citation has been created via Citoid, is "Generate", then "Insert", and then (if desired) "Edit". An alternative flow would be "Generate", then either "Insert" or "Edit", and if "Edit" was selected, then - after editing - clicking "Insert" (or "Apply changes")

I understand the argument that it's a bit irritating to click "Insert" when you're not completely happy with what was generated, and then needing to click "Edit" to fix things, rather than being able to edit the generated content immediately, before it is inserted. On the other hand, the current flow involves only one more click, and it avoids adding complexity (two choices rather than one) in the flow. -- John Broughton (♫♫) 21:09, 28 July 2015 (UTC)

Hi, I have the feeling that I regularly find external links in references that VE put inside nowiki tags: [18], [19], [20], ... --NicoV ^{(Talk on frwiki)} 07:42, 30 July 2015 (UTC)

Filed phab:T107431; this seems to be a recent regression in the citation tool. C. Scott Ananian (talk) 15:32, 30 July 2015 (UTC)

I went to edit List of sites on the Queensland Heritage Register in Toowoomba.It's a terrible mistake to try to edit it in the VE. As the name suggests, it's a list, which is being presented in 2 column format. It took me a while to work out why I could not click and edit (ahh .... I'm inside a template ... when the template is filling all your screen, you don't immediately realise this, unlike say an infobox). Once I'd realised and gone into the template editor, I then got to see the bulk of the article squished into a a small textbox as a "field" inside the colbegin template. And it was all presented in markup because it's just a field of a template and it was chocka-block with link syntax, citation syntax, image syntax. I think it would send the VE-only user running screaming. It's the least "visual editing" experience you could have -- it's just source editing in a really tiny text box! But I am not at all sure what can be done about it. Apart from multi-column, are there any other templates out there likely to contain huge chunks of an article, because those kinds of templates are going to be a real barrier for the VE-only user. Sigh! Kerry (talk) 13:19, 30 July 2015 (UTC)

Discussed previously here, here, here, and here. The first of these does have a bug report.

Multi-columnar lists seem to me to be a highly desirable feature. I'm guessing that underneath the ((colbegin)) template is some code that VE could recognize as specifying multiple columns, and VE could then display the list in a way that is easy to edit, and then could save the edited list, upon exiting VE, so that the underlying code is unchanged for wikitext editing (unless, of course, the user decides to change the number of columns, the column width, etc.)

Or, to put it more simply, it looks to me like multi-column lists is a feature that VE should add, just as it added (eventually) the ability to edit tables. -- John Broughton (♫♫) 18:19, 30 July 2015 (UTC)

I believe that we would have to get columns directly supported in wikitext first, which is phab:T95739. Alternatively, one of the epic requests to be able to change template content without opening the template dialog (e.g., change the birthdate in an infobox just by selecting the birthdate and typing) would probably achieve this (for most of the column templates, at least). Whatamidoing (WMF) (talk) 19:31, 30 July 2015 (UTC)

Hi, VE is still creating empty titles in article with just a nowiki tag as the text of the title, ==<nowiki/>==, like here. --NicoV ^{(Talk on frwiki)} 16:29, 3 August 2015 (UTC)

In this edit (DIFF) I removed the ((more footnotes)) hatnote with VE and it ended up removing all space between the remaining ((About)) hatnote and the single-curly grouping of elements for the ship infobox. In the subsequent edit (DIFF), I fixed this by adding a single carriage return. Visual Editor does have a tendency to be stingy about blank space, removing more than it needs to in some cases, such as this one. I think this created a problem here because of the (to me) odd infobox beginning boundary syntax {|((, which means that I think this would be a quite rare occurrence, but one to consider when polishing features. Regards --User:Ceyockey (talk to me) 22:47, 27 July 2015 (UTC)

This is likely a problem with any template that is present immediately before any table, not just for that one (elderly) infobox system. Whatamidoing (WMF) (talk) 23:26, 3 August 2015 (UTC)

What is the intention in relation to the VE? Is it intended to be the only editor someone uses and therefore has to be fully capable of doing everything without resorting to markup? Or is it intended to be an entrypoint for new contributors and used by occasional contributors but not for "heavy duty" editing and that, somehow, active editors will switch over to be source editors (out of necessity). The reason I am asking what the intention/strategy is relates to how the VE treats markup. When in the main text box of the VE, markup cannot be added. If I start typing [[ or (( etc, I am dumped into the Link gadget, the Template gadget etc. Now that is probably OK if I "typed" those characters, but what if I am pasting them in? This time it gets wrapped in nowiki tags and there is no way in the VE to remove them. How do I add some markup source (typically copied from some Wikipedia documentation or emitted from a tool)? Yet, if I am looking at the fields of a template, I am shown markup and can add markup without restriction. But if I want to add more fields to a template (e.g. I often want to copy in a set from something like Template:Infobox_Australian_place/Blank#Pushpin map fields, but I have no easy way of doing this in the VE. If I review my changes in the Save box, I am again shown markup but cannot change it. It seems totally inconsistent to allow markup to be shown and edited in some places in the VE yet refuse to allow it in other places. It seems to suggest a very confused strategy.

I write a lot of new articles. I cannot use the VE to do the initial edits because I am typically drawing from a set of standard citations (with some slight customisation) that I use all the time (see User:Kerry_Raymond#Favourite text and citations) and adding infoboxes like Template:Infobox_Australian_place or Template:Infobox historic site, both of which have a massive number of parameters. If I was forced to do that work in the VE, my productivity would slump massively. The difference in the time to just paste these things in vs do them via the VE's approach is orders of magnitude. Yet, I quite like the VE for doing small edits to existing articles, Citoid is very useful, etc. But it's quite clear to me that the VE does not have any path for a new user to became a very active contributor because creating a lot of new content isn't realistic in the VE. It might grow the community of occasional editors (which is not a bad thing of course) but it will not create replacements for retiring very active editors without having to re-educate them to use the source editor. All tools are inaccessible to the VE user because of this inability to insert markup using the VE. Also most of our existing documentation is expressed in markup, e.g. the first thing the Template:Coord does is provide information on how to use it as markup, which presumably makes it uninterpretable by the VE user. I really believe that the VE must support an "insert markup" capability in the main text box and in some other key places like the addition of template fields or else it becomes too limiting to use and lacks a path to "grow" new editors into regular active contributors. Or to put it another way, as much as I want to use the VE, I still am forced to do the bulk of my new content contribution in markup because the VE does not appear to be designed to support that. Kerry (talk) 22:52, 27 July 2015 (UTC)

Kerry - I'm not disagreeing at all with your comments, and I'm interested in how others respond to them, but I do want to note that one strategy for using VE is to open a page you want to copy from - open it using VE - then copy/paste from that page into the new page you're building, a page you're also editing using VE. With this strategy, you can use VE only for modifications; you don't have to build citations. -- John Broughton (♫♫) 20:51, 28 July 2015 (UTC)

That's a good idea. I think it will work for the citations, but probably not the infoboxes, but I'll experiment. Kerry (talk) 21:26, 28 July 2015 (UTC)

I don't want to discourage anyone from sharing their views, but the overall intention is for VisualEditor to be the only editing tool that someone needs to use – and for people to make their own choices about which editing tool they want to use. This means, therefore, that the intention is for VisualEditor to be fully capable of doing everything without resorting to markup. That’s not to say that VisualEditor is perfect in its current state, or that there are no edits that cannot be made in the current version without switching to wikitext.

However, at the moment, nearly all normal content creation can already be done in VisualEditor, especially if your favorite sources are supported by the citoid service. As John points out, if you have 'standard' items, you can copy and paste them from another page. It will always be true that each editing system has its strengths and weaknesses. Formatting lists is faster in VisualEditor; adding a single parameter to a template is slower. Eventually, changing contents of an infobox will be easier, because the hope is to be able to click on the text in the infobox and change it directly, just as if you were editing the contents of a table. However, that may be several years from now. We have users who have used VisualEditor hundreds of times for content creation and who consider it to be fully capable for their purposes.

Finally, though it’s not the reason why VisualEditor is this way, exposing wikitext in certain places there is a path for a new user to become familiar with wikitext. If you make an edit and review the changes, then you can see exactly what wikitext markup is used to represent the links, styling, and other formatting that you added. This gives interested editors an opportunity to learn wikitext if they want to. Whatamidoing (WMF) (talk) 00:14, 4 August 2015 (UTC)

Thanks for the explanation. I thought that was the intention (that you could be VE-only). In case it may not come across, I am actually very much a supporter of the Visual Editor. But trying to do The Right Thing and migrate across has not proven easy. Kerry (talk) 07:59, 4 August 2015 (UTC)

Some people have fully migrated. Harriet Gibbs Marshall is a new article that has never seen the wikitext editor, so it is certainly possible. I find that I switch back and forth, depending upon the task at hand. I will probably always do that. Whatamidoing (WMF) (talk) 23:44, 4 August 2015 (UTC)

Hi, in this edit, VE let a user add an incorrectly formatted reference in a template (<ref>...<ref>) without escaping anything, making the article completely damaged. On a following edit, VE made even more damages by adding nowiki tags all over the place. --NicoV ^{(Talk on frwiki)} 07:40, 23 July 2015 (UTC)

I can't reproduce this. When I paste in exactly the same ref, it properly escapes it. Whatamidoing (WMF) (talk) 19:36, 27 July 2015 (UTC)

Impressive how fast bugs that completely trash an article are simply dismissed as "Declined" after just a first answer that looks like as if the description wasn't read at all... --NicoV ^{(Talk on frwiki)} 19:29, 4 August 2015 (UTC)

The editor manually <ref>...<ref> (missing the slash to close the ref tag) into one of the few places in VisualEditor that accepts wikitext. The end result was exactly the same as if the editor had made the same typo in the wikitext editor.

I appreciate your faith that VisualEditor can always correct typos and other mistakes that editors add to templates, but the team apparently doesn't believe that compensating for typos in directly typed wikitext is a good use of their resources right now. They might be making this choice because of the relative rarity of the problem and also because eventually phab:T63505 or something similar will make this irrelevant. In the meantime, when editors make this typo within VisualEditor's template system, "Apply changes" will produce an obvious mess of monospaced wikitext on their screens, and clicking on the "undo" button will repair it. Whatamidoing (WMF) (talk) 23:13, 4 August 2015 (UTC)

Whatamidoing (WMF) The problem is that when the user made the mistake, VE did not even show the user the extent of the damages he would do. Try by yourself: redo in VE the error of the user and you will see that VE is not showing at all what the article will look like if you save. VE simply shows a damaged infobox, while the actual result is an article completely trashed. For a "Visual" editor, I would say it's clear failure...

But thanks for the explanation, at least I have one compared to the blunt and completely false "No actionables" comment made to decline the report. As you can see, this comment is not in line with your explanation. --NicoV ^{(Talk on frwiki)} 06:04, 5 August 2015 (UTC)

VisualEditor is getting better and better and I am finding places when it has advantages over wikitext. I just tried a bunch of italicizing and found that it is doing so in an inefficient way. See https://en.wikipedia.org/w/index.php?title=Flora_of_Brisbane&diff=674466821&oldid=674465340. If I click on the link Acacia fimbriata, then hit ctl i, it creates the text [[Acacia fimbriata|''Acacia fimbriata'']] instead of ''[[Acacia fimbriata]]''. It works, but rather than adding 4 characters it adds 21 and I hate to waste the electrons and make future editing harder.  SchreiberBike | ⌨  04:03, 4 August 2015 (UTC)

We should contemplate putting this into a FAQ. Someone asked this last week too. Whatamidoing (WMF) (talk) 23:48, 4 August 2015 (UTC)

Thanks, I guess there's no shortage of electrons.  SchreiberBike | ⌨  00:38, 5 August 2015 (UTC)

The problem is that the complicated wikitext is visible to those - the majority - who still edit using wikitext. So this is a bug. It's going to make life more difficult for editors - both in reading the wikitext, and if they decide that in a particular case that italics are incorrect.

And yes, it's better to explain this bug in a FAQ than not to, but the bottom line is that the developers chose the easiest path for them, not the best path for people who are editing. I understand that developer time is not unlimited, but again, this is a bug, and should be acknowledged as such, even if it's not going to be high priority to fix. -- John Broughton (♫♫) 22:17, 5 August 2015 (UTC)

This is an example of a "bug" which presents no problem to the VE user, but will presumably upset the source editor users who will think that this is something done deliberately/carelessly by the VE user and get upset with them (and the VE user will not understand what the fuss is all about). Kerry (talk) 05:32, 5 August 2015 (UTC)

Hi Kerry, thanks for this.

phab:T64147 covers the one-parameter-per-line issue. I have no estimate on when it will be resolved, and once it is resolved, then the TemplateData for all of the templates with a non-default arrangement will need to be individually updated to reflect the preference.

The wrong order for the parameters is a new bug. I’ve filed it as phab:T108133. Whatamidoing (WMF) (talk) 23:21, 5 August 2015 (UTC)

I edit a lot of articles with coords in the VE and this is the first time I have seen this overwriting, but most of the articles I work on have infoboxes, so I am guessing this may be the difference here. Kerry (talk) 05:26, 6 August 2015 (UTC)

This is a new-ish variation on an old problem. These "out of skin" templates (things that are typed here but display over there) are difficult.

The template is displayed (at the top right), which is why you won't find a puzzle piece anywhere. If you use arrow keys to move your cursor (right arrow over and over again) through the last couple of lines of the page, then screen will suddenly jump up to the top and select the coords template, right when your cursor reaches the point where the template is typed in the underlying wikitext. It is somewhat less than ideal and will hopefully be improved later. Whatamidoing (WMF) (talk) 18:44, 7 August 2015 (UTC)

Go into View History. Click undo, the source editor launches with the "undone" version of the article. Click on "Edit" to get into the VE, but you are given the current article not the "undone" one. Kerry (talk) 07:34, 2 August 2015 (UTC)

I asked about this, and eventually it will be possible. There's a long-term plan to unify the edit buttons (so everyone will have one "Edit" button, and you switch between VisualEditor and wikitext from within the edit window), and this will happen after that. Whatamidoing (WMF) (talk) 18:46, 7 August 2015 (UTC)

There are a number of reasons why one might want to edit a footnote that was built using a citation template (see mw:Help:VisualEditor/User_guide/Citations-Full#Manually_editing_an_automatic_citation if interested in those reasons), where by "edit" I mean doing something other than editing the template parameters.

Here's the current process to do so:

1. Select the footnote [but DO NOT click on "Edit"]
2. Click on the "Cite" button in the main toolbar
3. Choose the "Manual" tab [if you used this the last time you did a Cite, you won't need to do this step]
4. Click on "Basic form"

I'm going to venture that this is not at all intuitively obvious; in fact, I don't think people are going to figure this out at all unless they read the User Guide.

One option is to offer two buttons as step 2:

-- Click "Edit template" or click "Edit reference".

"Edit template" would be the equivalent of clicking "Edit", in the current process. "Edit reference" would replace steps 2 through 4 in the process listed above.

There are obvious objections. One is the possibility of confusing the user. A second is that there just isn't space to add two buttons (with longer labels) with what is a small popup.

So, here's a different idea for the flow; it consolidates what are now two different processes (editing the template, and editing the reference)

1. Select the footnote
2. Click on "Edit"
3. What opens is the Reference dialog, not the mini-template editor. The upper right button says "Edit template", not (greyed out) "Apply changes", if the footnote was built using a citation template. [VE already knows whether this is true or not.]

At this point, the user can (a) edit outside of an existing template, in the main editing area of the dialog (b) click "Edit template" to edit the template itself; (c) click on the template, then click "Edit" to edit the template itself.

Overall, this revised process adds one click to those who want to change citation template parameters, but saves two clicks for those who want to do anything else with the reference - expand the footnote before or after the template, copying the template, or changing the template to a different one. Its major advantage is that it eliminates the non-intuitive editing process discussed at the beginning of this section.

Having said all that, I'd be more in favor of this alternative flow if it didn't add a click to just about every use of Citoid, since - at least at the moment - building a citation using Citoid rarely results in a perfect footnote. So, today, "Insert" is almost inevitably followed by "Edit"; with the alternative flow discussed above, "Insert" would be followed by "Edit" and then by "Edit template". Perhaps that's an argument for the proposal made by GermanJoe, above [and quickly dismissed by JD] - footnotes built by Citoid should be editable before being inserted. -- John Broughton (♫♫) 22:07, 28 July 2015 (UTC)

John, at the risk of sounding dumb, I have to ask for an explanation. If I click on a footnote I built with Citoid, using cite web, and then click Edit, I get the dialog with "cite web" at the top and the template fields. If I go through Cite->Manual->Basic form I seem to end up in exactly the same place. What's the difference? Mike Christie (talk - contribs - library) 22:56, 28 July 2015 (UTC)

Mike Christie, to do this, you have to not click the "Edit" button. You have to click the "Cite" button in the toolbar (with the citation selected). The workflow made more sense before the citoid service was enabled. Whatamidoing (WMF) (talk) 18:26, 29 July 2015 (UTC)

Just a note to say that Abbey in Design Research sends her thanks for these comments, and also for GermanJoe's below. Also, if anyone is interested in helping with research, then please sign up at https://jfe.qualtrics.com/form/SV_6R04ammTX8uoJFP (note that it's a different website and therefore different privacy policies, etc.). Whatamidoing (WMF) (talk) 18:51, 7 August 2015 (UTC)

In this edit, VE made many damades:

• An existing title was converted a list item, but with the title markup kept, and merged with the table below up to (including) the next title
• Categories were merge into a single line with the portal

--NicoV ^{(Talk on frwiki)} 04:50, 10 August 2015 (UTC)

Also, the recommender system is making only a very small number of suggestions. Now I realise you can't fit everything on that list since there are about 950 articles with Queensland in their titles (over 100 of which have it as the first word of the title). But why pick Koala, Qantas, Australian cattle dog, as high-priority possibilities for someone looking for a link to Queensland -- none are that closely related. The recommender system appears to be favouring articles without the word Queensland in them but which have a redirect title that include the word Queensland over articles that actually include the word Queensland in their titles? Also where are the short article summaries coming from. I see some that are just wrong -- but they don't appear to be in the article itself or in the Wikidata (I'm not an expert on Wikidata) so their origins are mysterious to me. Kerry (talk) 01:35, 10 August 2015 (UTC)

• @Kerry Raymond: Hi! Thanks for the report. I don't usually respond to messages here because I'm not working on VisualEditor, but I am working on our search systems which, amongst other things, generate the results you see in the link dialogue in VisualEditor. So, here I am! Looking at the query that VisualEditor ran to get the results for the link dialogue, it seems like there are a few errors in the response relating to the ordering of the results. This might explain why the ordering doesn't make much sense to you. Looking at it, it seems that the first result should have been Queensland since it's an exact match, but that clearly didn't happen here. I'll file a bug to get this fixed. --Dan Garry, Wikimedia Foundation (talk) 05:29, 10 August 2015 (UTC)
• @Kerry Raymond: Task filed, see phab:T108554. I'll get my team to look into it. --Dan Garry, Wikimedia Foundation (talk) 05:34, 10 August 2015 (UTC)
• That task is a duplicate, as it turns out. Discussion and work continues at phab:T92796. --Dan Garry, Wikimedia Foundation (talk) 19:44, 10 August 2015 (UTC)

I realise you can add categories within the Visual Editor but if you have HotCat enabled, you expect it to be activated whenever you are in Read mode.Kerry (talk) 22:30, 6 August 2015 (UTC)

@Kerry Raymond:, this looks like Wikipedia:VisualEditor/Feedback/Archive_2015_2#HotCat_not_available_after_VE_save which has been tracked 6 weeks ago and been moved to Backlog. I added the tracking number above (but feel free to change it, if it looks like a different problem for you). However, the task is not on the board of current VE tasks ([22]) for some reason. GermanJoe (talk) 22:51, 6 August 2015 (UTC)

The team is not currently working on items in the backlog, so they are not displayed on the workboard. The workboard has been rearranged to show only things that they're actually intending to work on in the near-term (including definitions of "intending to work on" that resemble "intending to talk about" at the weekly triage meeting). It's a new system, and I'm still figuring out all the details.

(Personally, I will be looking forward to having this bug fixed.) Whatamidoing (WMF) (talk) 19:07, 7 August 2015 (UTC)

Thanks for the clarification. I hope the list of backlog tasks will still be visible somewhere else now - editors are supposed to report bugs and should be able to see them. Do you know by chance, where the backlog can be listed outside of the main board? (I tried a few queries, but failed) GermanJoe (talk) 01:22, 8 August 2015 (UTC)

Hi GermanJoe, I have figured it out: On the work board, find the "Manage board" button in the upper right corner. Then "Show hidden columns", and wait (and wait) for the page to reload. "Backlog" will be the first column. Also, if you see anything older that ought to be re-considered as a blocker now, then I suggest posting the Phab ticket number at mw:VisualEditor/Feedback. James F usually has a look there right before the triage meeting, so it's a good way to catch his attention at the right moment.  ;-)  Whatamidoing (WMF) (talk) 18:19, 11 August 2015 (UTC)

Hi, since Wikimania I have started using V/E for the first time in a while and it has greatly improved. But I don't see how to edit the content of tables in V/E for example this requires me to get out of V/E and revert to the classic editor. Is this a known problem or have I just missed the obvious? It does give me the option to delete rows or columns and sometimes that might be neater than classic editor, but I didn't spot how to change contents of a cell. ϢereSpielChequers 09:31, 4 August 2015 (UTC)

Double-clicking in a cell puts the cursor in the cell, and you should then be able to add or remove text. Mike Christie (talk - contribs - library) 09:35, 4 August 2015 (UTC)

Also, you can select the cell and press the Return key. It's not a great system, and will be up for review later (after links and citations, I believe). Whatamidoing (WMF) (talk) 23:49, 4 August 2015 (UTC)

I'm using Foxpro on Ubuntu and neither of those worked for me, though the search replace thing did work, but this isn't intuitive. ϢereSpielChequers 11:32, 8 August 2015 (UTC)

I've filed the bug, and mentioned you in it, so it will be in your list. Whatamidoing (WMF) (talk) 18:22, 11 August 2015 (UTC)

I think two-column format is one of the most common customisations of a reflist template. Certainly it's a lot more common than chosing between "general" and other reference groups (which is what I assume the dropdown is all about). I've seen very few articles that make use of that feature (just reading the documentation would put you off). I certainly think VE-only users are much more likely to be wanting to reformat their reflist (as they can see other articles with alternative formats so they know it's possible) than choose a reference group. Kerry (talk) 08:42, 8 August 2015 (UTC)

Odd. ((reflist)) is a template; editing it should invoke the template editor, as (for example) editing an infobox does. And there is template data for this template: https://en.wikipedia.org/wiki/Template:Reflist#Template_data. So yes, if VE is treating this as a special case [which would be interesting, since we've been told that VE won't treat reflist as a special case for finding the text of footnotes], VE should offer a way to invoke the template editor. -- John Broughton (♫♫) 17:28, 9 August 2015 (UTC)

@Kerry Raymond: The article in its earlier version uses "oldschool" <references /> (just as VE does when you click "Insert references list), not the ((reflist)) template. Both variants look very similar through VE, but are not exactly the same. The former version does not support columns and thus doesn't offer the template's parameters for editing. Someone mentioned the possibility of implementing a columns function for <references /> as well a while ago, but I have no current info on that topic (should be somewhere in the archives, if you are interested). GermanJoe (talk) 17:49, 9 August 2015 (UTC)

Ahh, I created the article in the VE and, when I used "Insert > References List", I was assuming that the generated wikitext would be ((reflist)). So, for the VE user, if they click on the reference list in some articles, they will get the <references /> behaviour (with the dropdown with General) and when they click on the reference list in another article they will experience the behaviour of editing the reflist template. How does the VE user make sense of this when their mental model is a visual one (these both look identical on-screen)? Certainly it was an interesting experiment for me to try to "solve the problem" using only the Visual Editor (and not cheat and do it in the source editor) -- it confused me completely. Is there any merit in having both references tag and the reflist template visible to the VE user? If all references tags were converted to reflist on ingest to the VE and only reflist templates emitted from the VE, then the VE user would only see reflist templates and not be confused. There would be no harm done to the source editors as they are not confused by references tag vs reflist template because they can clearly see which is in use. Over time, the VE would gradually convert most references tag to reflist templates, but I cannot see the harm in that since the reflist template is very widely used already. Kerry (talk) 00:00, 10 August 2015 (UTC)

If/when VE fixes the issue that makes references in ((reflist)) update while editing, then that would be harmless, but even then I don't think it's something VE should do, because ((reflist)) is a template designed by en-wiki, not a part of general MediaWiki software, whereas VE has to function across all wikis. Mike Christie (talk - contribs - library)|

OK, that's not the solution, but what is? Leave the VE user dazed and confused -- the mission is to allow people to edit exclusively in the VE. Right now, you have to use the source editor to see what's really going on. Kerry (talk) 07:10, 10 August 2015 (UTC)

I'm glad that you figured out the workaround. The only good news here is that new editors are unlikely to run into this problem, because they won't begin with a belief that the local template is the normal way to display references in a MediaWiki page.

One part of the solution is probably for people to stop using the reflist template in the vast majority of articles where they don't actually want its features (pointless server overhead to produce exactly the same results^[1]). Then people would stop expecting a local template to be the only or primary way to dislay references. At minimum, this would require people using AWB to stop replacing the wikitext code with the local template, and probably also to change the Article Wizard to using normal wikitext.

Another part of the solution is for <references /> to be expanded to cover the most common cases, like wanting columns for long lists (handy at the many wikis that don't have the English Wikipedia's reflist template). By the way, the columns should be dynamic, so that you don't end up with two unreadably narrow columns on smartphones, and two needlessly wide ones on large desktop screens. Most editors set columns to 30em or 35em these days (so you type ((reflist|30em)) in wikitext, or insert it in VisualEditor and set the "Columns/Column width" parameter to 30em.)

I make no bets on which of these two will happen first, and I expect that the answer is "not soon" in both cases, but native support for columns in MediaWiki at least has a bug number: phab:T53260. Once that's implemented, VisualEditor will start supporting it. Whatamidoing (WMF) (talk) 18:45, 11 August 2015 (UTC)

Dan.mulholland (talk) 06:01, 10 August 2015 (UTC)

Hi Dan.mulholland,

We're running 1.26 now, and I believe that the problem has been fixed. Can you upgrade to the latest (or something from last month)? I don't remember seeing any reports about this problem since June. Whatamidoing (WMF) (talk) 18:48, 11 August 2015 (UTC)

I tried using V/E to fix a typo halfway through a large article, clicked edit on the section heading but then found I was in edit mode for the whole article and back at the start of the article. I assume this is another unfortunate consequence of V/E not supporting section editing, but if you are reading a long article and spot something you want to fix the classic editor is much better and far more intuitive because it leaves you in the same part of the article (as well as all the other advantages of section editing re edit conflicts and speed). ϢereSpielChequers 06:17, 11 August 2015 (UTC)

No, it means that they're having nasty problems with scrolling. If you click the edit button on the section heading, then it ought to scroll back to (at least approximately) the same spot. Firefox, right? (There are different bug numbers for different browsers.) Whatamidoing (WMF) (talk) 19:00, 11 August 2015 (UTC)

User agent: Mozilla/5.0 (X11; CrOS x86_64 7077.95.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.90 Safari/537.36

I tried to run a url from jtor through the citaiton generator, and it didn't work correctly. Tried directly through Zotero instead, and got a correct citation (Malin, Irving (1963-04-01). "Review". The Kenyon Review. 25 (2): 348–352. ISSN 0163-075X. JSTOR 4334331. ) . I thought we were feeding zotero data through our tool...

Sadads (talk) 18:40, 6 August 2015 (UTC)

Hi Sadads, it's not limited to Zotero, but I believe that Jstor is run through Zotero, and there's a known problem with it. If memory serves, when citoid talks to Jstor, then Jstor wants one of the cookies from your computer, and of course citoid doesn't have the cookies on your computer. It's on the list, but I'm not sure how long it will take to fix. Whatamidoing (WMF) (talk) 18:33, 7 August 2015 (UTC)

Actually that's not the case, we solved the cookie problem- phab:T93877. This is a different problem :). Mvolz (WMF) (talk)

Thats odd, and interesting, and odd. You would think most JStor citations are in the common database for Zotero, so you would be able to just pull from that data-> instead of having to scrape it everytime. If you need direct contacts with JSTOR (since its one of the most highly used citations on Wikipedia), you can ping me via WMF email, and we can start a conversation. It would be neat to be able to take a JSTOR id, and turn it into a citation. Right now JSTOR citations are added ~ 1000 times a month, and we can only expect to get more. Most JSTOR articles also have DOIs, so you might be able to scrape that information off the page and use the DOI metadata, Sadads (talk) 19:09, 7 August 2015 (UTC)

Zotero doesn't have a public database that we use; we use their software, which scrapes the data from the website directly. Unfortunately the JSTOR translator isn't enabled for outside the browser which is why we weren't using Zotero for it; however, I just tested the translator and it seems to work for some URLS (but has partial failure according to the tests) which should improve this for some urls. Tracking enabling the translators here: phab:T108826 Mvolz (WMF) (talk)

Sadads, more tracking: the URLs that Zotero doesn't work on appear to be the DOI ones, which of course have a DOI we can use- unfortunately it doesn't currently work due to phab:T108832. There's another issue with the DOI urls, phab:T108831; this is why some of the urls you tried didn't work at all, and gave you the unable to make a citation for you message. It is potentially difficult to resolve, but phab:T108832 is easily fixable which means we might be able to have fairly good coverage for JSTOR once phab:T108826 is merged and phab:T108832 is fixed. That said, I think that the doi urls are root of the problem for both citoid and zotero- it causes a 500 internal server error in Zotero, and it causes memory leak warnings in citoid- neither codebase can get the html from JSTOR, which suggest to me there might be a root cause on JSTOR's end that causes problems for both Zotero and citoid. Since we can work around this by using the DOI in the url, it's not a blocker for us, but if people at JSTOR are interested in making their site more web-scraper friendly (which generally websites don't!) then I would certainly be willing to help debug with them :) Mvolz (WMF) (talk)

@Mvolz: Thanks for the great information! I will introduce you to our JSTOR contacts, and hopefully we can get them working in the right direction (or a useful direction). I know Google Scholar does a pretty good scrape of that data. Do you have contacts there? They may have a strong workaround. Sadads (talk) 15:14, 12 August 2015 (UTC)

Also, as a pet peeve: I would love to be able to throw something in citoid, and have the option for the reference not be a footnoted reference, just a citation template (to add into a Works Cited section for Harvard Footnotes, or to a "Further readings section"). The <ref> tags add about 4-5 more clicks and changes when I am in that situtation, Sadads (talk) 19:12, 7 August 2015 (UTC)

And I may have all the details wrong, so who knows. I'll point the devs at your note.

On the other idea: you and me both. phab:T95702 covers it, but I think it's in the "don't hold your breath" priority level. With John's help, we finally have a description of the workaround for extracting the template from the ref tags at mw.org, but it's Not Exactly Intuitive. Whatamidoing (WMF) (talk) 00:16, 8 August 2015 (UTC)

@Whatamidoing (WMF): Sorry for the slow response, didn't see a ping. I made an argument on the phabricator bug for including this intuitively. The current instructions are bogus: no-one is going to take the time to do that, you have to be an experienced Wikipedia editor to understand that process and ... we really need the auto-generated citations to be an option (probably as part of that "reference type selector" as a check box or something). Sadads (talk) 15:35, 12 August 2015 (UTC)

On OTRS-wiki, VE is enabled and discussions occur on mainspace pages (e.g. here for those with access). I just tried to post a reply with VE, and had two problems... I didn't know how to thread my post as I usually would using :, and secondly I couldn't add my signature with ~~~~ - nor could I find a signature under the "insert" dropdown. Any ideas? --99of9 (talk) 03:19, 12 August 2015 (UTC)

Hi 99of9,

This is because neither of these actions are possible. Signatures will not be added; it's been deemed off-limits as scope creep. What we call "indentation" is actually the HTML for half of an association list (a.k.a. definition list). It actually shouldn't be used in that context at all (but what else can we do? Wikitext doesn't have an actual indentation code). VisualEditor will eventually implement association lists. It's not clear whether you will be able to add only the "definition" (the :indented part) without the "term" (the ;bold part), however. Whatamidoing (WMF) (talk) 02:49, 13 August 2015 (UTC)

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36

Trying to create a page well... I can't create one using this tool, but using the normal way I can!

I suppouse it's an error or something

Klonoa TDInc (talk) 03:33, 17 August 2015 (UTC)

Hello, Klonoa TDInc, and welcome to Wikipedia. Thank you for reporting this problem. I really appreciate it. It was fixed a little while ago. Whatamidoing (WMF) (talk) 18:19, 17 August 2015 (UTC)

There was a standard link to a Wikisource article

• [[s:Declaration at the Congress of Vienna|deceleration outlawing Napoleon]] deceleration outlawing Napoleon

this was changed by user:Kinnerton using VisualEditor to fix the spelling error (deceleration --> declaration) with this edit (17 April 2015) to

• [//en.wikisource.org/wik0i/Declaration at the Congress of Vienna declaration outlawing Napoleon] at the Congress of Vienna declaration outlawing Napoleon

There was no reason for a change to be made to the link to Wikisource. Is this standard behaviour or is it done using a switch? -- PBS (talk) 08:03, 10 August 2015 (UTC)

If there's a change being made, it ought to be going the other way. I'll get you a bug number. Whatamidoing (WMF) (talk) 18:50, 11 August 2015 (UTC)

phab: T108718. If this has been fixed since then, then someone will mark it as a duplicate of the original report. Whatamidoing (WMF) (talk) 18:54, 11 August 2015 (UTC)

the explanation given in phab: T108718 is that the Wikisource links is changed to an html link during edition and user:Kinnerton accidentally added a a zero into /wiki/ so that /wik0i/ no longer correspond to the Wikisource links so it was not converted back at the end of the edit. IE it is not a bug in the editor but an editor mistake.

It seems strange to me to place non-human readable gibberish into a WYSIWYG editor, and in doing so it is not surprising to me that this sort of error occurs. -- PBS (talk) 18:18, 18 August 2015 (UTC)

Arising from a conversation on the research mailing list, Jonathon Morgan compiled a list of the most active VE users over the last month, revealing that User:Megalibrarygirl was the top user of the VE and I noticed that this user had experienced a dramatic increase in edits since switching to the VE about 6 months ago and is now using the VE for almost all her edits. So I wondered if there was a connection between the high productivity and the VE. So I asked her and yes the VE has made a big difference. Read here for what I said asked and here for her reply. So, there's a VE success story! Maybe you want to interview her for Signpost or something! Kerry (talk) 00:17, 18 August 2015 (UTC)

Thanks for the links. Whatamidoing (WMF) (talk) 03:22, 19 August 2015 (UTC)

Another thing arising from the training session this morning. Two new user accounts (created in front of me). We then went to Preferences to enable the Visual Editor. One of the new users (but not the other) already had the VE enabled. What's all going on here? I know there was a A/B experiment about the use of VE by new users conducted a while back for research purposes. Is that still running? Kerry (talk) 03:59, 17 August 2015 (UTC)

Note. There was no problem arising from this -- just my surprise. Kerry (talk) 04:00, 17 August 2015 (UTC)

VisualEditor is being gradually deployed to all new users, as a result of a community discussion last month. I believe that 25% of new accounts have access to it automatically right now. That will probably go up to 50%, and then 100%. (The system operates by fractions, so their plan is 1/20th of new accounts, 1/10th, 1/4, 1/2, and then 1/1.) Assuming that there are no further delays, then the deployment process will end around September 1.

Also, they're looking into moving the location of the prefs setting. VisualEditor is getting kind of big for Beta Features, so the Beta Features "opt-in" button may become a normal "opt-out" button under Special:Preferences#mw-prefsection-editing. They need to preserve the settings for active/experienced editors if they make that switch, so figuring out whether they can do that reliably is the first step there. Whatamidoing (WMF) (talk) 18:28, 17 August 2015 (UTC)

Can you point me to a consensus to make VE an opt-out feature on English Wikipedia?—Kww(talk) 23:44, 17 August 2015 (UTC)

Wikipedia:Village pump (proposals)/Archive 125#Discussion - Gradually enabling VisualEditor for new accounts. PrimeHunter (talk) 23:55, 17 August 2015 (UTC)

That discussion is about offering VisualEditor to new accounts. What I'm talking about is really just a technical change to the location of the prefs, from Beta Features to standard prefs. Because the prefs are written to be opposites, then the settings have to be opposite: if you are "ticked" in Beta Features then your account has to be "unticked" in prefs. This should all be done automatically. If Kww (for example) is currently not opted-in under Beta Features, then his account would be automatically opted-out under prefs. The change should not be noticeable to him, unless he spent a lot of time looking at his prefs settings and happened to notice that VisualEditor stopped being mentioned on this prefs page and started being mentioned on that prefs page. Whatamidoing (WMF) (talk) 17:01, 18 August 2015 (UTC)

Is the default setting for accounts going to remain unchecked, so that new editors still have to opt-in? Or are you changing it to opt-out? If you are switching from opt-in to opt-out, describing that as merely a technical change that I shouldn't notice strikes me as being profoundly dishonest.—Kww(talk) 15:11, 19 August 2015 (UTC)

Unless I've misunderstood this, the two things are independent. It's changing to opt-out, for new editors only; that's discussed at the page linked by PrimeHunter. Independently of that, the location of the flag to choose whether VE shows up in your skin is moving from Beta Features to prefs. Either of these could be happening without the other; they're not connected, as far as I can see. Mike Christie (talk - contribs - library) 15:15, 19 August 2015 (UTC)

Mike is correct. The plan is to maintain the settings for experienced editors. If you have VisualEditor now, then you will have VisualEditor then; if you don't now, then you won't then. The point is to move the setting from one page in the prefs to another page in the prefs. The new setting would look like this, where it says "Temporarily disable the visual editor while it is in beta".

If they change settings for anyone, then it will be discussed on wiki first. I'll ask them if it would be more convenient to do that (e.g., for dead accounts) at the same time as moving the prefs. Whatamidoing (WMF) (talk) 17:07, 19 August 2015 (UTC)

Regarding the preferences, yes, I think the time has come to shift it to being an Editing preference rather than a Beta preference (could it stay as both?) Kerry (talk) 00:05, 19 August 2015 (UTC)

And where's the preference to opt-out of the source editor? OK, I won't be doing it but I can imagine VE-only users would like to get rid of that "Edit source" button. It would also resolve the question of whether clicking on a redlink drops you into Create or Create source, ditto for Undo, etc. If you have both enabled, you can get either. If you only have one enabled, then that's the one you get. Kerry (talk) 00:11, 19 August 2015 (UTC)

And when do we get to give feedback on the VE using the VE? For those of us who are long-time source editor users, our feedback is "tainted" by the mental model we have constructed from the use of the source editor. A VE-only user will almost certainly have a different mental model of what is going on with an article and will use different language to describe their experiences. Their expectations of behaviour will be different too. Kerry (talk) 00:15, 19 August 2015 (UTC)

Lots of replies:

• The devs don't permit multiple prefs buttons for the same thing, so it can't stay as both.
• You can't opt out of the wikitext editor. Eventually – maybe months, maybe a couple of years – they'll be "merged" similar to what is done on Mobile Web (if you're opted in to Mobile Beta, which is different from Beta Features, which in turn is different from a beta version. Also, there's a Beta Labs, just in case someone wasn't thoroughly confused yet). That will give you one "Edit" button, and you can switch back and forth between wikitext and VisualEditor from inside the edit window.
• VisualEditor is available (in a limited form) in Flow. If you'd like to see it in action, then drop by mw:VisualEditor/Feedback and say hello to James F. Whatamidoing (WMF) (talk) 03:20, 19 August 2015 (UTC)

At the end of the session, we did some experimentation. If you do a Cite > Manual > Basic and just paste in the URL as text (not with []), you can create a citation with the bare text URL. That seemed to work, so it is a work-around of sorts. Also, one of the trainees was able to create citation containing that live URL on the Moggill, Queensland article (see this diff). But it was not possible to add that same citation on either user pages nor on the newly created articles James Francis Maxwell and Harry Massey. I created those articles earlier that morning for the training session using my own user account; the articles were not created by the new user accounts; the new users were just expanding the stub. So the problem seems to involve the intersection of three things: a new user account, a new article (the Moggill, Queensland article was not new) and a citation with a "live" external link. Can I be advised ASAP when this bug is fixed so I can get back to the trainees and let them know. Obviously they left the training session believing that they cannot do citations to websites, which is a big limitation and may get them in trouble with other editors if they omit citations because the VE won't let them insert them.

Also, one trainee was using my laptop (the one I normally use for Wikipedia editing and using Chrome as I normally do), so the problems with citation are not linked to anything to do with their browser/operating system. As an established user, I could create citations when as a new user, they could not. Kerry (talk) 03:11, 17 August 2015 (UTC)

Hi Kerry, it should be fixed now. Looking back through the code, the devs say that this problem started late Thursday UTC, was first reported on Friday evening UTC, and they fixed it today. Would you mind asking your new editors to try it out to make sure that it's completely fixed for you now (assuming that they aren't both already autoconfirmed)? Thanks, Whatamidoing (WMF) (talk) 18:23, 17 August 2015 (UTC)

Not sure if they will still be unconfirmed but I will email them and see if they can give it another go. Thanks all for fixing this speedily! I guess my observation that the age of the page was relevant must have been random coincidence. Kerry (talk) 23:43, 17 August 2015 (UTC)

One of the users has attempted adding a citation and it succeeded. See the diff. I think the account was less than 4 days old at that point so would not have been autoconfirmed (where do I look to tell if they are autoconfirmed?). What I cannot say is whether they got the Capcha right the first time or not. But at least thi s user will now believe that they can add citations. Yet to hear anything from the other one and the user contributions suggest no edits since the bug is believed to be fixed. Kerry (talk) 07:09, 20 August 2015 (UTC)

Thanks.

I couldn't find any way to look up autoconfirmed status, so I asked one of the devs, and he didn't think it was possible outside the API or Special:UserRights (which is mostly admin-only, I think). Autoconfirmed status varies by project. Here, it's four days and 10 edits. You can get easy access to both of those numbers by copying the "File:userinfo.js" lines from m:User:Whatamidoing (WMF)/global.js into your global js page at Meta. Reload the page and then go to the user's page or talk page. There will be a new line with that information right underneath the page title. Whatamidoing (WMF) (talk) 17:10, 20 August 2015 (UTC)

And it turns out that the API isn't just for bots! Try this link to see the results for my volunteer account. You can edit the URL to change the username. Whatamidoing (WMF) (talk) 17:14, 20 August 2015 (UTC)

In teaching the VE yesterday for the first time, I encountered an interesting thing about categories. Now, as a source editor, I find the position of the categories in the VE completely non-intuitive. But yesterday I discovered so do VE-only users. Because they see the categories (in Read mode) at the bottom of the article, they expected to find them in the bottom of the article in Edit mode. Maybe the categories should be displayed as a clickable box (as is done for infoboxes and images) at the bottom of the article and clicking it takes you to the category editor. Kerry (talk) 00:22, 19 August 2015 (UTC)

There's been a suggestion about making something similar to HotCat since June 2013. It is a low-priority task, but it might happen some day. An interim possibility is just to display the cats at the end of the page, and when you click them, to have it open the same dialog box for categories that you get from the Page options (thee bars) menu. If anyone has preferences or ideas, then please feel free to post them here (or at the Phab task). Whatamidoing (WMF) (talk) 17:17, 20 August 2015 (UTC)

Red Fiona (talk) 23:03, 17 August 2015 (UTC)

Red Fiona, it seems like Citoid incorrectly recognized that URL as containing a DOI (because "1024088/dika_toua.html" looks superficially like a DOI), so it treated it as a journal citation. I've filed that as a bug (you can see it at the link to the right). Thanks for the excellent report!—Neil P. Quinn-WMF (talk) 23:18, 18 August 2015 (UTC)

Thanks. And that explains why it's only the biographies that do that. Red Fiona (talk) 12:39, 22 August 2015 (UTC)

Take a look at List of tunnels in Australia#Queensland. In read mode, you see a bullet list starting with Airport Link as the first entry. Open it in the VE and you see an extra empty list item at the start of the bullet list. Try to delete it - can't! When I look in it in the source editor, there is indeed an empty bullet list item (that is a line consisting just of "*"). I am not sure what the right thing is to do here, to not display it at all since it cannot be manipulated and isn't seen on-screen anyway or allow it to be deleted. In a way, there is also a "bug" in the Read mode when the empty item isn't displayed. 23:48, 20 August 2015 (UTC)

Kerry, are you sure that you can't you delete it? Put your cursor at the start of the previous line, and press backspace. Whatamidoing (WMF) (talk) 16:19, 24 August 2015 (UTC)

Yes, you are right; it can be deleted that way. But it didn't occur to me to go to the following line when my cursor was sitting on the line in question. I tried to backspace over it and to select the bullet and delete, neither of which worked. Kerry (talk) 20:31, 24 August 2015 (UTC)

Kerry (talk) 20:50, 24 August 2015 (UTC)

BIG RizZ (talk) 11:19, 26 August 2015 (UTC)

Hi BIG RizZ, and welcome to Wikipedia. Was this on your private wiki? There was a bug about this back in June or so, and it's been fixed in a later release. (I can't find the bug number right now.) Whatamidoing (WMF) (talk) 18:03, 26 August 2015 (UTC)

How do you find citations in a large article in the VE? You can see in read mode that you are looking at a naked URL citation

[13] ^ http://someurl.com

and you would like to find it in the article and make it a better citation. However the VE won't let you search for 13 or for someurl as its Find tool doesn't look inside citations, infoboxes, etc. Could there be some tickbox to allow searching within them? Kerry (talk) 00:42, 26 August 2015 (UTC)

Aside. I appreciate why you probably can't support searching for 13 but for anything thinking visually, they might wonder why not. But it ought to be possible to search for non-generated text within the citation.Kerry (talk) 00:46, 26 August 2015 (UTC)

I think that this is a good idea.

In the meantime, you might see if this kludge is saves you a (very) little bit of time: "Re-use" the ref (anywhere on the page). Fix it. Now delete the one that you just fixed. VisualEditor should copy the fixes to the original location when you delete the temporary copy. Whatamidoing (WMF) (talk) 18:14, 26 August 2015 (UTC)

I completely agree with John Broughton in the thread above (and "not intuitive" is a polite understatement). Just listing some minor problems and flaws in a new thread (to avoid hijacking the other):

1. The design mixes "Insert" and "Edit" functions in the same Cite window structure.
2. In "Edit" situations, the UI doesn't even bother to update the window labels and still shows "Add citation".
3. Starting to "Edit" an existing reference with this special workflow above, VE displays a second reference box in the article. Just a glitch, but it's confusing. It should only display the activated reference in this specific situation, as there will be no new reference after this workflow.
4. Technically inactive functions like "Cite news" on an activated "Cite web" reference are still active and just open the "Cite news" template editor. (again not terribly wrong, but confusing)
5. The design doesn't really reflect the relation between "Cite basic form" and "Cite XYZ" and just lists them as equal forms of citations. "Basic form" is also not that descriptive as name. (But I have no better idea for either aspect, it's difficult to be fair).

In summary, every flaw on its own is not that bad really, but together they make that workflow unintuitive and unsuitable for any new or inexperienced editor. GermanJoe (talk) 19:33, 30 July 2015 (UTC)

Minor comment on #4: I'm not very happy with "Basic form" either. For one thing, it's not really a "form" at all, especially compared to the template dialog. Does anyone want to brainstorm some other options? Whatamidoing (WMF) (talk) 18:53, 7 August 2015 (UTC)

@Whatamidoing (WMF): the word "form" seems to me to be a net negative - it can be read as a fill-in-the-boxes "form", as opposed to meaning "type" (as in "basic type"). I think things would be more understandable if the option just read "Basic" - as in "basic footnote" or "basic reference". Alternatively, "Non-template" or "Non-standard", I suppose, though one can insert a template, and I'd guess that there are wikis where the basic cite is in fact the standard (normal) one. -- John Broughton (♫♫) 22:57, 9 August 2015 (UTC)

I've suggested matching "Basic", which is what's in the non-citoid-enabled Cite menu. Whatamidoing (WMF) (talk) 18:26, 11 August 2015 (UTC)

The citation template appears to have stopped working entirely. Has it been damaged?Rathfelder (talk) 09:10, 21 August 2015 (UTC)

Are you sure, that issue is related to Visual Editor? The "Cite" feature for source editing currently has some problems, see Wikipedia:Village_pump_(technical)#Cite_tool_fails. In Visual Editor the Citoid menu can disappear (very rarely), but the complete Cite template function has never vanished afaik. If the problem happens in Visual Editor, please open a new thread and specify your operating system, browser version and as many details as possible. GermanJoe (talk) 10:09, 21 August 2015 (UTC)

Hi Rathfelder, can you describe what's happening? Is it still a problem? Whatamidoing (WMF) (talk) 16:25, 24 August 2015 (UTC)

the template appeared, but the boxes in which you insert information didn't. But I am pleased to report it started working again on Saturday morning.Rathfelder (talk) 18:59, 24 August 2015 (UTC)

Please let me know if it happens again. Whatamidoing (WMF) (talk) 18:36, 26 August 2015 (UTC)

GermanJoe, I think I've finished getting all of these ideas entered into Phab. Let me know if I missed anything. Whatamidoing (WMF) (talk) 18:36, 26 August 2015 (UTC)

Thanks for that (one day I'll get used to Phabricator myself). Reference and template handling are probably two of the more difficult areas of course, due to the complexity of the used elements. Just need to continue to tweak them based on additional user feedback. GermanJoe (talk) 18:56, 26 August 2015 (UTC)

It is almost impossible to upgrade a citation in the Visual Editor. Consider for example the last citation in [23]. In markup it is:

<ref name="ReferenceA">Wayne Goss remembered as courageous Queensland reformer [http://www.abc.net.au/pm/content/2014/s4125404.htm ].</ref>

Now, I can tell from the URL that this is a news story, so I want to create a News citation (a format which the VE supports). But the VE regards the existing citation as a Basic form with an embedded URL and only allows me to do Basic form editing, so I cannot create a News citation. OK, I have to create a new one and then delete the old one. But I need to copy information (title, URL) from the old one. So, having started creating the new News format citation, I need to open the old one to copy the URL. Ah, I cannot do that because I have to close the old citation to do that. So you find yourself opening the old citation, copying a bit of inforation, adding it to the new citation, closing the new citation, opening the old citation, copying some information, etc. Truly painful. Could we allow having both citations open so it's easier to copy and paste between them? Kerry (talk) 01:04, 26 August 2015 (UTC)

I don't know if it's possible to have both open at the same time. I've asked at phab:T110357.

In the meantime, perhaps either of these approaches would be easier:

1. Open the existing ref. Copy something. Click at the end of the existing text, and Insert > Template. Choose a citation template. Paste in the first item. Close it, and you're automatically back in the still-open Basic ref. Copy the next thing. Re-open the new template and paste it. When you are done, remove the now-unwanted original text from the beginning of the citation field. (This has the happy advantage of preserving the ref name.)
2. Open the existing ref. Copy the URL. Close it. Create a new ref, and use Citoid to fill it. (This will not preserve the ref name.)

Whatamidoing (WMF) (talk) 17:38, 26 August 2015 (UTC)

That first workaround is a neat trick! Thanks for that! Kerry (talk) 00:53, 27 August 2015 (UTC)

Editing Wayne Goss. Copied citation [6] from Gossia (which was opened in the VE, showing there as citation [5]) and added to end of last sentence in the section "Death funeral and legacy". Deleted wikilink to Gossia from the See Also section. Tried to Save Page. Unable to save due to "parsoidserver-http: HTTP 500". Allows me to dismiss it and return to editing, but all further attempts at saving fail with the parsoid error message. Reproducible. Kerry (talk) 00:31, 27 August 2015 (UTC)

Instead of saving, I tried switching to the source editor. That is just hanging with a candy-striping movement across the "Keep Changes". Definitely not happy about something. Kerry (talk) 00:44, 27 August 2015 (UTC)

The problem appears to be the copied citation (not the deletion of the bullet point). The citation I am trying to copy is (in markup) <ref name=Floyd-2008/> so I don't know whether it being a citation reuse is a problem but there is nothing particularly unusual about its definition

<ref name=Floyd-2008>[[Floyd, A.G.]] (2008) ''Rainforest Trees of Mainland South-eastern Australia''. Inkata Press. ISBN 978-0-9589436-7-3. page 243.</ref>

Kerry (talk) 00:41, 27 August 2015 (UTC)

This is a bug in VE where the newly created reference in HTML is incomplete and Parsoid is unable to convert it to wikitext. So, Parsoid throws up its hands and refuses to convert the page instead of creating buggy wikitext. SSastry (WMF) (talk) 03:12, 27 August 2015 (UTC)

@Kerry Raymond: This is because the reference isn't a real reference but created inside a ((reflist)) template. It warns you that you can't edit that kind of reference when you select it, but it doesn't stop you from copying it, which then goes (as you spotted) disastrously poorly. Software-side, the solutions are for Parsoid to just drop false-references when they come in (rather than 500ing), and for VisualEditor to not let you copy these references anyway. Content-side, don't write references inside a references list (which is ugly), and if one must, definitely don't do so inside a templates references list (which is evil). Sorry for the difficulty; we'll get it fixed at our end right away. Jdforrester (WMF) (talk) 18:15, 27 August 2015 (UTC)

… and, trivially, once I'd manully fixed the Gossia article using VE worked fine. Not that that's much help for others. :-( Thanks for the find. Jdforrester (WMF) (talk) 18:22, 27 August 2015 (UTC)

Apparently, when you type an ISBN in VE, it's now escaped by nowiki tags (the whole sentence). For the last 2 years, ISBN handling was very poor (modifying an ISBN gave very bad results), and it's now even worse as even basic feature is completely non functional. Are there any tests performed before a release ? --NicoV ^{(Talk on frwiki)} 15:18, 26 August 2015 (UTC)

Nico, based on the nowiki classification that you and Amir made (which was quite helpful), over the last month, our two teams have been focusing on nowikis a lot more and making fixes in both Parsoid and VE. We had a bug in Parsoid where plain text that looked like urls and ISBN links were not being nowikied and when we fixed that, VE-side bugs got exposed (which caused the uptick in nowikis around bare urls and ISBNs), and Scott has made fixes in VE to prevent those. But, given the deployment schedules, VE-side fixes are slightly behind Parsoid-side fixes. The nowikis-around-url VE-side fix went out last week, and the nowikis-around-ISBN VE-side fix is going out this week. So, after Thursday Aug 27, these nowikis around ISBNs should go down a lot. Overall, since August 12th, the nowiki count on frwiki has reduced (avg. 28/day aug 1-12, and avg 23/day aug 13-25), and we expect they will go down further after Thursday. SSastry (WMF) (talk) 16:23, 26 August 2015 (UTC)

Related phab tickets are phab:T107431 and phab:T54204. I've been working on ISBN and magic link issues for the past two weeks. The final piece is phab:T63558, and most of the code for that is in Gerrit now. C. Scott Ananian (talk) 17:03, 26 August 2015 (UTC)

SSastry (WMF) : 28th and still nowiki around ISBN, like here. And for the 27th: 36 VE edits triggered the nowiki abuse filter... --NicoV ^{(Talk on frwiki)} 10:03, 28 August 2015 (UTC)

Ah, that's an interesting case: an ISBN with trailing punctuation. I opened phab:T110690 for this. C. Scott Ananian (talk) 15:59, 28 August 2015 (UTC)

Note, this diff is the same as the one in the bug above about underscores in the wikilink, but both appear to be independently reproducible, so I don't think the two are related. I think I just got unlikely to hit two problems in the one edit. Kerry (talk) 21:12, 24 August 2015 (UTC)

Hi Kerry, you have to press backspace twice to remove that image: once to select it, and once to delete it. It should scroll to display the selected image. This works for me in both Firefox and Safari. Can you try it again (slowly), and let me know if it's not selecting and scrolling the image for you? Whatamidoing (WMF) (talk) 17:28, 26 August 2015 (UTC)

I did it slowly (a number of times). It goes like this. I open Charters Towers with the VE. I click my cursor before the first word "The" of the History section. There are a couple of empty lines above it with a photo to the left and the infobox to the right. I press backspace. Nothing appears to happen except the "Paragraph" on the toolbar turns blank (the cursor does not move, there is no change to the empty lines above). There is no scrolling or movement in the text box. I press backspace a second time. The "Paragraph" empty space now becomes "Heading" on the tool bar and the cursor is now positioned at the end of the word "History" in the section title. The Save Page button on the toolbar is now turned blue (which I think means it has deleted the blank lines even though are still displayed, but I know that the VE is not 100% WYSIWYG so I am OK about that -- of course what has actually happened is I have deleted the photo off screen). There has been no scrolling movement in the text box -- just the cursor moved. If I now save, the photo is gone. At no point (without actually scrolling down to look for it) do I see the funeral photo highlighted and then removed by the 2 backspaces. Sounds like it is Chrome-specific bug? Kerry (talk) 23:55, 26 August 2015 (UTC)

That's a great description. Yes, it seems to be Chrome-specific. I've filed it as phab:T110700, and tentatively marked the priority as high, since the team has historically thought this kind of issue was important. Whatamidoing (WMF) (talk) 16:49, 28 August 2015 (UTC)

Kerry (talk) 00:34, 26 August 2015 (UTC)

This is a long-standing bug that I don't expect to see solved any time soon. (Note that you also can't re-use those refs, because they aren't "in" the article.) Whatamidoing (WMF) (talk) 17:31, 26 August 2015 (UTC)

Since I gather it can't be easily fixed, maybe it's better not to number them then, instead just put them as^[#] as at least that forces you look for the preceeding words to locate the citation rather than rely on the number being correct. It might do less harm that the present situation does when you replace the wrong citation.Kerry (talk) 00:15, 27 August 2015 (UTC)

I've suggested that here. Whatamidoing (WMF) (talk) 17:05, 28 August 2015 (UTC)

A really good and powerful feature which most text editors (like Vim, Kate...etc) have is word completion or autocomplete. The editor tries the guess the word being typed by offering the set of possible choices from words already mentioned in the file (in this case, the edited article). This would reduce typos by a great margin and even reduce editing time. Currently there exists no such feature in regular source editing via scripts or gadgets that I know of. -Ugog Nizdast (talk) 18:47, 27 August 2015 (UTC)

Like spelling correction, this is something that your browser would have to do. Whatamidoing (WMF) (talk) 17:11, 28 August 2015 (UTC)