From Wikipedia, the free encyclopedia
Jump to: navigation, search
Share your feedback
Report bugs
Your feedback about VisualEditor

Use this page to tell the Wikimedia developers your ideas and issues about using VisualEditor. All comments are read, but personal replies are not guaranteed.


Please click here to report a problem with VisualEditor.
Please include your web browser, computer operating system, and Wikipedia skin (usually Vector, sometimes Monobook).
Please click here to make a suggestion.
Ideas about user interface choices and the priorities for adding new features are especially welcome.

Other ways to contact the team More

Help Local archives

How to put a reference at the end of my sentence?[edit]

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)

Click this to add a citation
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)

Minor Error[edit]

Bug report VisualEditor
Description Deleted last sentence of text in Naomi-Lee Fischer-Rasmussen. Couldn't add anything after the text that was left.
Intention: Was trying to add her results from the 2012 Summer Olympics.
Steps to Reproduce: Haven't tried to reproduce it, but the last sentence (see this diff for what they looked like) contained two links. I deleted the sentence. I tried to add more text after the end of the article. I could not write any text after it. I saved the page, re-opened and it worked fine.
Results: I could not write any text after the new end of the article.
Expectations: I should be able to write text after I have deleted other text.
Page where the issue occurs Naomi-Lee Fischer-Rasmussen
Web browser Chrome 43.0.2357.134
Operating system Windows 9
Skin Vector
Notes: Any additional information. Can you provide a screenshot, if relevant?
Workaround or suggested solution Save page and re-open. Worked fine the second time.

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)

Section edits shift the page up and down the scrollbar on change of focus[edit]

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)

VisualEditor "insert row" doesn't insert enough columns[edit]

Bug report VisualEditor
Description VisualEditor "insert row" doesn't insert enough cells.
Intention: I am using VisualEditor to edit a table as part of a reformatting/cleanup edit. I successfully used it to add and populate a new column. However, when I attempted to add a new row, it added too few columns, and added them all as "Header" type. The table has 11 columns, but the new row only had 8.
Steps to Reproduce: Table being worked on can be found here.

Once editing, I click the left most cell, then click the arrow that appears. I choose "Insert above" or "Insert below"

Results: A new row is added, with 8 cells. Each cell is set as a "Header" cell.
Expectations: A new row with 11 cells, and only the first set as a header (Or, none set as header).
Page where the issue occurs
Web browser Chrome 43.0.2357.134 and Internet Explorer 11.0.9600.17843.
Operating system Windows 7 Professional 64-bit
Skin Vector, also tried Monobook.
Workaround or suggested solution

-- 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)

Problem with {{Sfn}}[edit]

Bug report VisualEditor
Description {{Sfn}} does not work
Intention: To cite a source using {{Sfn}}
Steps to Reproduce: #Add info
  1. Click on "insert" and then on "template"
  2. Search for and select Sfn
  3. Fill in parameters
  4. Click on "insert"
Results: A footnote and reflist was created.
Expectations: Just a footnote
Page where the issue occurs
Web browser Google Chrome Version 43.0.2357.134 m
Operating system Windows 7
Skin Vector
Notes: Screenshot: Visual Editor - problem with Sfn.png
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)

A Warning When Article Doesn't Contain A Reference List[edit]

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 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)

Awful table formatting[edit]

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)

Handling links to other wikis[edit]

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)

Null edits not supported in VE[edit]

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)

Incorrect ref : article completely damaged by VE[edit]

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)

Editing automatic citations[edit]

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)

Infobox Editing Malfunction[edit]

Bug report VisualEditor
Description Infobox editing malfunction when adding fields
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.
Screenshot of VisualEditor editing infobox error
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)

Useless nowiki tags added for regular single quotes[edit]

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)

Useless nowiki tag added after a template[edit]

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)

Putting article content underneath the categories[edit]

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)

Place to type changes as they are made[edit]

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)

removing a hatnote template with VE created a formatting problem[edit]

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)

VE and markup: a question about intention/strategy[edit]

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)

Editing an existing footnote that is a citation template[edit]

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)

External links in references put in nowiki tags[edit]

Hi, I have the feeling that I regularly find external links in references that VE put inside nowiki tags: [1], [2], [3], ... --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)

Article in multi-column format[edit]

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)

Some flaws in the current "Cite" design[edit]

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)