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

When trying to add a thumbnail:

1. press "Insert" -> "Media"
2. choose a file -> "use this image"
3. write a caption
4. select a word in the caption to wikilink, press the "link" button
5. choose an article to link to, press the "done" button
6. before clicking "insert", click your cursor into or just after the linked word, a "link" box will show up again with an icon and a supposed bluelink to the article... but if you right click that link (or the one in the text box) and open it in a new tab it goes to en.wikipedia.org/w/linkname instead of en.wikipedia.org/wiki/linkname, and thus causes a 404 error

--99of9 (talk) 07:35, 18 August 2015 (UTC)

Thanks. That's definitely a bug. I'll get you a bug number tomorrow. Whatamidoing (WMF) (talk) 04:00, 19 August 2015 (UTC)

This is fixed now. The fix will be live on Wikipedia on Thursday September 3rd. --Roan Kattouw (WMF) (talk) 18:28, 28 August 2015 (UTC)

GermanJoe (talk) 22:53, 26 August 2015 (UTC)

• Hm, and now the function is OK again when I edit the same article and insert a CN template. But "Auto value" failed just 10 minutes before - I saw it, really. Here's the diff for it. GermanJoe (talk) 22:53, 26 August 2015 (UTC)
  • It's happening again at Zafar Iqbal (doctor) just now. Selecting the template, I get the message "You are adding the "Cn" template to this page. It doesn't yet have a description, but there might be some information on the template's page." ==> It looks like, VE is unable to retrieve TemplateData information, although the information is perfectly fine in the template documentation (and worked 1 hour ago). GermanJoe (talk) 18:53, 27 August 2015 (UTC)
    • I just asked an admin to do a null edit on the template, and it's working for me now. I'll tell the devs about it, but please let me know if it continues to be a problem, or if it comes up on any other templates. Whatamidoing (WMF) (talk) 17:24, 28 August 2015 (UTC)
      • @Whatamidoing (WMF): - problem re-occured yesterday afternoon and is still occuring c. 20 hours later. ((vague)) with a similar TemplateData and other templates still work fine and load their TemplateData, it's only ((cn)) with these weird re-occuring problems. Looking at the template's TemplateData section, I noticed that it uses TABs to format the visual code layout, but afaik that should be OK (maybe worth double-checking with the devs, if TABs are an allowed character in that file structure - just to be sure). GermanJoe (talk) 08:30, 30 August 2015 (UTC)

Same bug as previously reported, which seemed to have been fixed, but over the past few days has been back with a vengence. Invoke the VE, the toolbar appears and the whole screen is "greyed" but the progress bar never appears and the toolbar etc never becomes active. No cure apart from clicking Read to abort the load, and then having another go. Kerry (talk) 08:57, 31 August 2015 (UTC)

I passed along the word, and they think that the most likely (and most annoying) cause is a "corrupted cache at [your] ISP". This is a problem normally solved by waiting; there's nothing you can do about it. Whatamidoing (WMF) (talk) 15:56, 2 September 2015 (UTC)

James F. has started a discussion at WP:VPPR about offering VisualEditor to inexperienced editors. The "gradual deployment process" has finally finished, so new accounts will all have access to both VisualEditor and the wikitext editor now. There are several parts to this proposal, but IMO the most significant is that it would retroactively opt-in editors who were missed during the last couple of months of the gradual deployment process (e.g., 75% of the editors who created an account during the week when only 25% of new accounts were being opted in, the other 50% in the week when 50% were being opted in, etc.). Please share your ideas at the discussion. Whatamidoing (WMF) (talk) 17:35, 3 September 2015 (UTC)

In this edit on Burketown, Queensland, I managed to generate some mangled wikitext.

I wanted to replace the naked URL citation (http://www.savannah-aviation.com) with one generated by Citoid. I opened the citation to copy its URL. I then deleted the citation. I then did Cite > Automatic and pasted in the URL, then Generate. Citoid went to work and proposed an acceptable citation, so I inserted it and saved.

But the wikitext emitted is broken. Now while I might have done something not exactly as described above, I am at loss how anything I did within the VE could have produced such broken wikitext. How could I have ended up with unbalanced ref tags? Any thoughts? Kerry (talk) 07:15, 4 September 2015 (UTC)

The Savannah Aviation reference was a "basic" citation with additional Cite functionality within the "Cite basic" window itself - is it possible, that you accidentally clicked "Cite Automatic" within the "Cite basic" window and then deleted the created URL information? That can easily happen, as a citation within a basic citation can be removed with 1 single click (it counts as 1 connected field and is only displayed as long string).

It's possible to create such a broken reference intentionally via VE in "Cite basic" (just tested): insert a single blank character into a new basic citation and click "Insert". VE seems to accept that as valid reference content, but fails to create functional code for it (the generated code should probably be <ref> </ref> instead of <ref />) (minor VE problem) - or VE could simply refuse to insert such an entry. GermanJoe (talk) 16:56, 4 September 2015 (UTC)

You have to have something in the box, or VisualEditor won't allow you to Insert the ref. (One space is enough; the space is removed by Parsoid and collapsed down to the <ref /> tag.)

Kerry, do you happen to remember looking at the ref (its the context menu) after inserting it? Do you remember what it looked like? Whatamidoing (WMF) (talk) 18:20, 4 September 2015 (UTC)

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

URL: https://en.wikipedia.org/wiki/User:Dhulipalla_Narendra_Kumar?veaction=edit

Dhulipalla Narendra Kumar (talk) 12:55, 4 September 2015 (UTC)

Welcome to Wikipedia, Dhulipalla Narendra Kumar. I'm not quite sure whether you are asking to WP:MOVE the page or to delete your account. I think you may want to post your question to Wikipedia:Teahouse/Questions, where experienced editors are happy to help new contributors. Whatamidoing (WMF) (talk) 18:23, 4 September 2015 (UTC)

So I decided to test editing of Template:Use British English. It has one parameter (a date field) and no TemplateData set up for it. In the Add a template dialog, I click "Add template", and see, in very faint grey, "No unused fields". The user guide (in draft), says:

Use numbers as the name for each nameless parameter. The first un-named parameter is named 1, the second is named 2, and so forth.

So, I type "1", and click on the offered field. "No unused fields" is still in faint grey, which is odd - I just used the only available field.

I type in a value for the field, then go to the "Field name" box, and type in "2". VE offers me the ability to set up a second parameter/field, which I take. I add a value for that parameter. No warning that I've used two many paramaters. The faint grey text is unchanges: "No unused fields".

I click "Insert"; the template is added to the page. No warning of an excess parameter. I save the edit. No warning of an excess parameter.

It wouldn't surprise me if VE hasn't figured out, without TemplateData, exactly how many parameters are in a template. But if that's the case, why is there text in the dialog box that certainly strongly implies that VE is tracking this? -- John Broughton (♫♫) 20:17, 6 September 2015 (UTC)

Red Fiona (talk) 01:28, 11 September 2015 (UTC)

Hi Red Fiona, thanks for this report. I'm sorry you encountered this, but glad that you persisted so that you could tell the teams so much about it. I've already talked to one of the product managers about this, and they're looking into it. Thanks, Whatamidoing (WMF) (talk) 16:32, 11 September 2015 (UTC)

The standard format for displayed mathematical equations is like

:<math>x^2+y^2</math>

which displays as

${\displaystyle x^{2}+y^{2))$

with a single : indentation. I can't see a way to create this in VE at the moment. The equation editing dialog gives a normal, block and inline option for equations these create <math display="block">...</math> etc, which centers the equation rather than giving the stand one level indentation.--Salix alba (talk): 20:56, 4 September 2015 (UTC)

The CSS for the display block seem to be specified in extensions/math/modules/ext.math.css.--Salix alba (talk): 21:46, 4 September 2015 (UTC)

I think it might be fixable with some css style rules

.mwe-math-fallback-image-display,
.mwe-math-mathml-display {
    margin-left: 1.6em !important;
    margin-top: 0.5em;
    margin-bottom: 0.5em;
}

which seems to work OK for PNG, SVG and MathML modes.--Salix alba (talk): 22:15, 6 September 2015 (UTC)

I know I'm preaching to the choir, but the standard format for displayed mathematical equations should not abuse HTML association-list formatting (and screwing up everything for some screen readers) to get indentation. I'd be happy to have this implemented, if that meant that we could get rid of that indentation kludge. Perhaps User:Edokter could take a look at it? I assume that this is so standard that forcing it to happen is not going to upset anyone, and the soon-to-be-superfluous "indentation" could be stripped out later. Whatamidoing (WMF) (talk) 19:31, 7 September 2015 (UTC)

This 'abuse' has been going on since the beginning, and not just for math (in fact, you just abused it yourself...). But yes, a simple margin is just as good. Just replace every instance on margin-left: auto; margin-right: auto; in ext.math.css with margin-left: 1.6em;. (I trust flipping will be accounted for). Perhaps the HTML parser/Parsoid can substitute the colon for the display class. Didn't the old math code used to scan for :<math...? -- [[User:Edokter]] ((talk)) 20:27, 7 September 2015 (UTC)

phab:T6521 is an old bug. The fact that it's old, and that people have gotten into the habit of exploiting it, doesn't mean that it's not a bug. Whatamidoing (WMF) (talk) 00:54, 11 September 2015 (UTC)

So do I understand correctly that (1) Visual Editor is incapable of producing mathematical equations that have formatting consistent with the existing Wikimedia articles, and (2) by closing this bug on phabricator, the Wikimedia developers have indicated that they refuse to ameliorate this problem? Do we have any choice but to include "do not use VisualEditor and do not use display=block" in our mathematics formatting guidelines? —David Eppstein (talk) 18:02, 8 September 2015 (UTC)

I've now added the above CSS to MediaWiki:Common.css so things should appear fine here but not on all the other affected wikis.--Salix alba (talk): 09:36, 10 September 2015 (UTC)

The second part does nothing; inline is already the default. Also, 0.5em top/bottom margin would match default paragraph margins. -- [[User:Edokter]] ((talk)) 15:42, 10 September 2015 (UTC)

Indeed, it seems my own javascript was conflicting. You seem to be right on the 0.5em. I've fixed the css accordingly.--Salix alba (talk): 17:12, 11 September 2015 (UTC)

One big missing feature in the VE is the lack of an indentation tool to increase or decrease the wiki-style semantic indentation of content (the equivalent of prefixing a line with more or fewer ":" characters in wikitext).

If this was to be implemented using the same UI as typical word processors, with "increase indent" and "decrease indent" buttons, this would be instantly familiar to anyone who has ever used a word processor (hence zero learning curve), would instantly and intuitively eliminate problems like the math indentation problem above, and also help greatly with the eventual use of the VE for editing talk pages, something which only really now requires a signing tool and indentation control to deal with 95% of use cases. Given how I understand the VE to work, an indentation control should be trivial to implement. Can we have this, please? -- The Anome (talk) 15:30, 10 September 2015 (UTC)

It is there for bulleted and numbered lists. HTML does not have a indentation element without using CSS. The way wikipedia does this is by miss-using the DD element produced by the : syntax. There is a task for implementing definition lists T39938 a fix to that might allow indention.--Salix alba (talk): 15:44, 10 September 2015 (UTC)

Correct. However, wikitext is not HTML, and has not been so for a long time. The current implementation of the ":" prefix does indeed currently abuse the DD notation (bad): but it also has 15 years of highly significant use as semantic markup throughout Wikipedia, particularly on talk pages, and thus constitutes core wikitext functionality. Almost all uses of : in wikitext are currently used for this purpose: its uses for description lists are few and far between. To eliminate its use in this way the VE would be to completely eliminate one of the core constructs of wikitext. We should support it internally as such: the rendering to HTML is a mere matter of presentation, and CSS would be fine for this.

Note also that none of this contradicts the idea of CSS special-casing of ":<math>" proposed above. Indeed, it would aid it. -- The Anome (talk) 15:55, 10 September 2015 (UTC)

I haven't talked to the team about this yet, but I suspect that if phab:T6521 were fixed, then supporting "true indentation" would be immediately added to the VisualEditor and Parsoid team's worklists. Their fundamental problem is presumably this:  : and ; in wikitext produce bad HTML when used for non-association lists. One of the design requirements is not producing bad HTML (it's actually possible to run VisualEditor without wikitext at all, in a pure HTML system). But currently the only way to produce both good HTML and to get an indentation is to add scary-looking HTML codes to each and every line that needs to be implemented—which, if we were to float that idea to the broader community, I think we could expect to go over in much the same way that a lead balloon doesn't.

The short form of the problem statement is this: HTML has at least two ways to visually scoot text over, and wikitext only has one. Wikitext needs to have two.

BTW, given the scale of the "semi-colon abuse", one approach to the limitation of wikitext would be to make : be a plain indentation, not part of the HTML association list, and then to send a bot or AWB through to update the relatively uncommon actual definition lists to some new syntax, like "==". Whatamidoing (WMF) (talk) 01:04, 11 September 2015 (UTC)

If a bot can do it as a one-time thing, why can't the wikitext parser do it on an ongoing basis whenever it converts wikitext to html? Wouldn't that be a cleaner solution, from the point of view of wikitext editors who don't necessarily want to add to the complexities they have to remember about how to write valid wikitext? —David Eppstein (talk) 02:18, 11 September 2015 (UTC)

A bot can "do it" because a bot can try, and then it can be manually corrected if necessary. Telling the parser to guess whether this:

;Word

:Definition

is "supposed to" be a definition list or not is something that an editor could not correct, if the parser got it wrong. Whatamidoing (WMF) (talk) 16:25, 11 September 2015 (UTC)

Hmm. The main context that I know of where ;: are common on Wikipedia is in the Book: namespace. But even there, they are not used in a way that matches the description-list semantics: instead Wikipedia Books are grouped into sections with one ;-line (the section heading) followed by many :-lines (the articles within the section). It looks like a description list but the intended meaning is quite different. If you want to get correct semantic markup, I think that should be treated as a third different usage of the semicolon and colon: it's not for indentation, but it's also not a proper description list. —David Eppstein (talk) 18:01, 11 September 2015 (UTC)

I'm afraid this hasn't been thought through all the way. VisualEditor does not permit users to sign pages. Contrary to what seems to have been assumed when this change was made yesterday (i.e., enabling VE throughout Wikipedia "project" space), the overwhelming majority of pages in Wikipedia space require users to sign their edits. It is not going to go well if new users, who may well have adopted VE when they start editing in article space, come to Wikipedia space and start getting yelled at for not signing their edits, or not being able to figure out what they have to do in order to sign their edits. (Bear in mind, I'm writing this 48 hours or so after we've just blocked a whole pile of "new user" like sockpuppets, and there is a high level of suspicion of new users right now.) Please reconsider this. I believe it will have a negative effect on uptake of VE by more experienced editors, and will result in unplanned newbie-bashing. Wait until you've figured out how to include a 'sign your edit' button in VE. Risker (talk) 04:01, 3 September 2015 (UTC)

Oh wow. It appears this was activated based on a single post to VPT saying, "I think we should enable Visual Editor in Wikipedia namespace or at least for sandboxes. What do you think?" The only response was that it wasn't possible. And on that basis we are activating software changes to namespaces? Where is "activate VE in other namespaces" on the roadmap? Risker (talk) 19:06, 3 September 2015 (UTC)

Oh dear. This is not good. The VE has massively improved (for which kudos to the hard-working dev team), and I would now be happy to have it implemented in the article namespace, but it seems to me that the interaction with the community is falling back into the old pattern, where the VE team seem disconnected from the very user communities who are best placed to help them by catching things like this. Come on, VE team, please engage with the community before making changes! Otherwise, I believe this deployment will be a fiasco, same as last time: comment signing is a big deal, as it constitutes a core part of Wikipedia's internal editorial and social processes. This is therefore core functionality for the encyclopedia, and allowing editing without signing breaks it.

@Whatamidoing (WMF) and Jdforrester (WMF): please can you do something about this ASAP, please, preferably by disabling this for now, going back and proposing a design solution for signing, then getting the user community happy with that before implementing and deploying? Risker is quite right about the risk of this resulting in unnecessary newbie-bashing. -- The Anome (talk) 19:38, 3 September 2015 (UTC)

@Risker, The Anome, and Magioladitis: Hey there. Sorry to hear that you're so concerned; I didn't agree that enabling VE in the project namespace was a great change myself, but I didn't feel strongly enough to oppose a normal community request which has been honoured on several other wikis. This configuration change has been live at a few wikis for months without issue; based on this evidence, I think that your concerns of increased newbie-biting or disruption, though laudable, are unlikely to be met. However, I'm happy to abide by your concern. I'll remove it now in the next config sweep (and thus this edit may be the last VE edit made in the project namespace for a while). I'd be happy to engage in a discussion between different community members who have different ideas about what settings make for the best experience, if that would be useful. Jdforrester (WMF) (talk) 22:48, 3 September 2015 (UTC)

To be honest my request had to do only with sandboxes. So, I have no strong feelings about anything. -- Magioladitis (talk) 22:51, 3 September 2015 (UTC)

Thank you, Jdforrester. From my perspective, the downside is the inability to sign edits, which is mandatory for editing Wikipedia space; most of the pages in this namespace are the same as talk pages, which are explicitly excluded *because* there is no signature option built in. I note that MatmaRex has indicated he made a gadget, but we can't expect newbies to know about those sorts of things. Risker (talk) 22:53, 3 September 2015 (UTC)

@Risker: And yet, I signed. ;-) (Using a hack I know because I'm an expert VE developer, not something actually useful.) But yes, VisualEditor is explicitly and intentionally designed for writing content, not discussions, and lots of things that we'd have to implement to make VE sort-of work for discussions would break (or at least hinder) VE for writing content. This is compromise I don't think makes sense. Jdforrester (WMF) (talk) 23:25, 3 September 2015 (UTC)

James, I'd put it to you that the reason that VE has been explicitly designed not to be used anywhere else is a philosophical one and not a practical one. And if the only purpose of VE is to write content, then there was no rational reason at all to turn it on in one of the two namespaces where the majority of the editing is not primarily content. I would have expected the VE team to say 'no, that's not the purpose of this software' and decline. It wasn't a community request, it was a misinterpreted request from a single user. VE shouldn't have been designed to be impractical to use anywhere but content space, and for the life of me I do not understand why there was a deliberate philosophical decision to weaken the greatest strength of the projects, which was that if you could edit one page, you could edit *any* page without having to learn new tricks or different interfaces. But heck, I just edit here. Risker (talk) 00:58, 4 September 2015 (UTC)

By pure coincidence Wikipedia:Village_pump_(idea_lab)#Auto_sign_on_talkpages started being discussed today. Implement that and you can stop worrying about newbies having to learn about tildas. ϢereSpielChequers 23:00, 3 September 2015 (UTC)

@WereSpielChequers: Hmm. Unfortunately, that idea has no hope of happening because it's technologically impossible. There's a reason the discussions system needs to be replaced, and this is it. :-) Oh well. Jdforrester (WMF) (talk) 23:25, 3 September 2015 (UTC)

Even if the relevant bit of the MediaWiki source code has been lost I very much doubt it is technologically impossible, maybe surprisingly difficult. But there are a couple of different routes that David Gerard (talk · contribs) and others mooted and I and I suspect they would be be interested to know what the technical barrier is. I've been lobbying for this for quite a while, and I don't remember anyone saying it was difficult before. ϢereSpielChequers 05:30, 4 September 2015 (UTC)

PS Was that a difficulty in adding signatures just in V/E or would it be a problem in the classic editor as well? ϢereSpielChequers 16:10, 4 September 2015 (UTC)

There is a task T53154 about adding a tool to add signatures in VE, but it is marked as WONTFIX. I disagree with this position, for a small bit of work VE would be usable in other namespaces. Yes it may not be as designed and may not be perfect for the task, but it would be possible. This becomes a lot more relevant now as it looks like Flow is being put on the back-burner. Flow being one of the reasons behind the WONTFIX.--Salix alba (talk): 09:01, 4 September 2015 (UTC)

Add a signature tool to the VE, and we may well have a solution. Flow is a dead end, at least for now; a perfect case of Mencken's maxim of "For every complex problem there is an answer that is clear, simple, and wrong".

@Jdforrester (WMF): I fail to see how auto-signing is technologically impossible: as far as I can see the vast majority of use cases where it would be appropriate are easy to detect programmatically, with essentially no false positives, and the rest can be handled via the signature tool and through social norms, in the same way that the use of signatures is enforced at the moment. Can you please explain? -- The Anome (talk) 11:13, 4 September 2015 (UTC)

The problem as I see it is that with the best will in the world, you would probably only achieve a 95% solution. That means that for the future you will have a lot of people complaining about the last 5%. So instead of solving 1 problem you would now have 2 problems that you need to maintain/communicate about and eventually u still need to replace it with a proper solution —TheDJ (talk • contribs) 17:00, 4 September 2015 (UTC)

I don't see the 5% as a problem. By the time people are ready to add wikiproject templates they should be capable of deciding whether to opt their account in or out of autosigning. ϢereSpielChequers 19:13, 4 September 2015 (UTC)

Exactly. -- The Anome (talk) 19:28, 4 September 2015 (UTC)

I kind of see TheDJ's point. As soon as talk pages are open to VE you have a new bunch of issues to deal with. For example you need a way to deal with indentation. Currently VE does no deal with the abuse of HTML which is the colon wikitext syntax. So thats yet another small thing which needs doing. I guess the more you look into it the more problems like this you can deal with.--Salix alba (talk): 20:40, 4 September 2015 (UTC)

Correct. This was the problem with the original deployment of the VE, and is the problem that also makes implementing Flow hard. Both are elegant, quick, simple solutions to 80% of the problem, and it's easy to see how that can lead to the impression that solving the other 20% was merely a Small Matter of Programming. Unfortunately, that 20% is not only full of Turing complete software (templates, Lua modules, and bots!), it's also full of people. who are even harder to deal with. This makes it a wicked problem. It's nice to see how much progress the VE has made, from disastrously overconfident deployment of pre-alpha software to the mature (but still far from complete) system that it is today. Bold ambitions are not a problem; over-confidence and misplaced optimism is. -- The Anome (talk) 14:33, 8 September 2015 (UTC)

@Salix alba: I declined T53154 because adding a signature button to the visual editor is like adding an ejector seat to a helicopter; yes, we can do it, but it's a really bad idea.

I spoke above about how the visual editor is written to make it good to "write content"; to make this more concrete, I'll give some examples:

• When you click edit on a section ('thread'), you probably by default want to add a new thought/comment/!vote to the discussion – so we should scroll you to the end, and put the cursor there. However, when you're editing content, you probably want to tweak something near the start of the (normally much shorter) section, so we put the cursor at the start and scroll to that.
• If you are replying to a thread (at the end), you'll have wikitext like * I think we should consider this in the light of [[WP:BBQ|this other discussion]] <sig>\n*: Yes I agree <sig2>; clicking the cursor at the end of that and pressing "return" needs to add a new menu item, and un-indent to the root. If you're writing content, instead you'd want to extend a list at the current indent level – something you'd almost never want to do when using the hacky "system" of OLs, ULs and DLs we abuse for unstructured wikitext talk pages.
• Conversely, if you are replying to a comment in a thread (at the end), with the same wikitext as above (* I think we should consider this in the light of [[WP:BBQ|this other discussion]] <sig>\n*: Yes I agree <sig2>), you'd want to put the cursor after <sig2>, press return and be indented by one, not outdented to the base level. Again, this would be actively not wanted for writing content.

And this isn't even starting on things like judging when people would want a <br /> vs. a </p><p> vs. a </li><li> when they press return mid-edit, or exactly which kind of list indenting bastardy they wish to inflict on this line, or…. :-)

Jdforrester (WMF) (talk) 23:49, 11 September 2015 (UTC)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:40.0) Gecko/20100101 Firefox/40.0

URL: https://en.wikipedia.org/w/index.php?title=Carus,_Oregon&veaction=edit

After editing this page in Visual Editor, I hit "Save Page", then got this error message: Something went wrong! parasoid-server-http HTTP 400

Miltritterprod (talk) 05:38, 14 September 2015 (UTC)

Hi there, Miltritterprod. As you can see from other reports above, this is known and getting resolved, and you can track related progress at https://phabricator.wikimedia.org/T112286 if you wish to do so. Best, --Elitre (WMF) (talk) 10:27, 14 September 2015 (UTC)

The VE is rarely loading for me over the past several days. Starts loading, screen goes grey, but no progress bar. It's become close to unusuable. A lot of my recent source edits have been because I just could not get the VE to load. Is this a VE problem? Is this some problem to do with my browser, my computer, my star sign?

I had been about to switch over to doing training on the VE but at the moment I don't think I can if I cannot work out my problem which will impact on demonstration and whether or not it is likely to affect the people attending the training. Also with the roll-out to new users, are they being affected by it? Can you tell how many attempted-but-failed loads are occurring? 22:44, 13 September 2015 (UTC)

Hey Kerry, I haven't heard other reports about VE not loading. I'd be happy to look into that. I'd need the title of a few articles where this occurred for sure, your browser and operating system name to see if the issue is consistent and reproducible. Thanks as usual for your feedback, --Elitre (WMF) (talk) 10:34, 14 September 2015 (UTC)

Odd nowiki addition. Not sure, why a nowiki tag would be added here - please forward this to the devs working on nowiki behaviour, if it's a new case (may be related to the ISBN case further up, but not sure - feel free to merge). GermanJoe (talk) 16:02, 7 September 2015 (UTC)

It looks like that is easily reproduced: Copy the (wikitext) ref, and paste it into VisualEditor. User:SSastry (WMF) might want to look at why so much of the paragraph was included in the nowiki range, but when you paste plain wikitext into an article, it is not unreasonable to expect it to end up inside nowiki tags. Whatamidoing (WMF) (talk) 19:45, 7 September 2015 (UTC)

A nowiki is also created, when I copy the reference string (without ref tags) into Cite basic, but then the nowiki tags are better placed: at the start and end of the created reference. So the reference string itself, even without the ref tags, contains a problem for VE. GermanJoe (talk) 20:28, 7 September 2015 (UTC)

Yes, known issue and there are WIP patches in the pipeline that will address this issue where nowikis wrap the entire text node instead of the substring of the text node that requires it. SSastry (WMF) (talk) 14:21, 8 September 2015 (UTC)

Great. < nowiki > oddness is one of the few remaining irritating features of the VE. -- The Anome (talk) 15:24, 10 September 2015 (UTC)

On a related note, because it's most often seen in bibliographic citations, pasting in an ISBN ("ISBN 123456890") as plain text triggers nowikis as well. Whatamidoing (WMF) (talk) 00:56, 11 September 2015 (UTC)

This should be fixed by recent code I wrote. See Wikipedia:VisualEditor/Feedback/Archive_2015_2#ISBN_are_put_inside_nowiki. C. Scott Ananian (talk) 19:45, 14 September 2015 (UTC)

SSastry, Cscott: In this edit, VE added nowiki tags around a big chunck of text, because someone typed text with 2 single quotes instead of double quote. But the nowiki tags should be around the problematic text, not extended to the nearby text in both ways up to the next single quote that is alone. --NicoV ^{(Talk on frwiki)} 15:44, 15 September 2015 (UTC)

Yes, known and I have a WIP on my laptop to address this. This should be addressed hopefully by end of this month. SSastry (WMF) (talk) 16:28, 15 September 2015 (UTC)

SSastry, Cscott: In this edit, VE added nowiki tags around nothing at the end of a table cell. --NicoV ^{(Talk on frwiki)} 15:48, 15 September 2015 (UTC)

Arlo has a patch that to address this in a generic fashion, but this will take a little longer to be finished, reviewed, and deployed .. since he is addressing this issue more generically and not tailored to this one case. Maybe 4-6 weeks. SSastry (WMF) (talk) 16:30, 15 September 2015 (UTC)

SSastry, Cscott: In this edit, VE damaged a working reference by putting nowiki tags around the opening ref tag. It's probably because the name attribute contains an opening quote and no closing quote. But before VE edit, the reference was displayed correctly, while the result with VE is a visually damaged article. Please fix VE/Parsoid so that articles are not damaged. --NicoV ^{(Talk on frwiki)} 15:39, 15 September 2015 (UTC)

NicoV, With broken wikitext, Parsoid will not be bug-for-bug compatible on all edge cases with PHP parser and so a few such normalizations will sneak through. That said, we have been trying to reduce some of those diffs -- see yesterday's deploy and August 26 deploy on that page. Once some more time frees up or we get more developer time, we will dust off our wiki-linting project (which you might remember from early conversations in summer of 2014), which might help by flagging broken wikitext and also providing options to fix them up or help WikiCheck do that. SSastry (WMF) (talk) 16:05, 15 September 2015 (UTC)

SSastry (WMF) The problem with this normalization is that the original article was correctly displayed but the result of the edit with VE is a truly damaged article. I'm sorry, but a normalization that ends up in visually damaging the article is a true bug for me, not just a normalization... --NicoV ^{(Talk on frwiki)} 17:20, 15 September 2015 (UTC)

NicoV, I understand what you are saying, and okay, I shouldn't have said normalization, but I was trying to explain that this diff showed up because buggy wikitext is handled differently in Parsoid and PHP parser. Not all wikitext errors (like in this case with a missing quote) will get treated identically. I don't consider this a high-priority bug in Parsoid unless these are extremely common in wikitext (which I doubt it would be). In a huge number of scenarios, Parsoid does leave these wikitext errors alone. But, once in a while, this will happen. As I pointed in the deploy logs above, we'll continue to tweak and finetune our attribute parsing code, but we will not guarantee that Parsoid and PHP parser will treat every single wikitext error identically. That is not a goal worth striving for. I don't consider it a useful investment of our scarce developer resources to fix this over the other nowiki scenarios that you have highlighted for us. A simpler fix in some of these cases would be to edit the page and fix the wikitext error. SSastry (WMF) (talk) 17:56, 15 September 2015 (UTC)

Hello, haven't really wrote in a long time but I noticed something and thought that it should be reported. I saw above some people saying that they were having problems with saving a page after editing. From what I understood they couldn't save at all... In my end, when I clicked save, my edit did get saved but instead of taking back to the article, the pop up window to save a page was still open. My summary was not there...it looked like I had just finished my edits and clicked "save page" at the top right button. I checked on history and saw that my edit was saved.

I am editing on Google Chrome, Windows 8. TeamGale ^(talk) 09:30, 17 September 2015 (UTC)

Hey TeamGale. It's such a pleasure to hear from you again. I think I have also experienced what you are saying a few days ago. I thought I hadn't saved at all (because I couldn't see my edit summary), while what happened is, simply, that it was still in the process of saving, so what I was seeing was the dialog which usually goes away immediately. I think this is due to occasional slowness (not sure if related to ISP or Wikipedia servers), but please let me know if this becomes a real annoyance. best, --Elitre (WMF) (talk) 15:00, 17 September 2015 (UTC)

Elitre, No, what TeamGale is talking about is a real bug. I have run into this a few times with Firefox. You save the page, but the save dialog doesn't get dismissed even after you have exited the VE view and entered the read view. I assumed that this is a known bug. SSastry (WMF) (talk) 17:24, 17 September 2015 (UTC)

SSastry (WMF), TeamGale, I'll check and if it isn't I'll file it. Thanks for letting me know, --Elitre (WMF) (talk) 17:34, 17 September 2015 (UTC) PS: Could be [1].

So if any of you finds out how to reproduce, instructions are welcome (you can put them directly at [2] or leave them here). --Elitre (WMF) (talk) 17:41, 17 September 2015 (UTC)

SSastry (WMF), Elitre Hi again. Thanks for filing it Elitre and yes, it was no matter of slowness since I waited for few minutes to see if it would go away and it didn't. And since SSastry mentioned it, I think in the background, the page was still in the edit view and not in the read view, but I am not 100% sure for this so don't take it for granted. I rarely edit the last few months due to lack of time but if I run into it again and figure out how to reproduce it, I'll write back with more details. Cheers :) TeamGale ^(talk) 14:07, 18 September 2015 (UTC)

In this edit, VE damaged a title, making a correct title into a mess with displayed "==" and text merged in the same line as the title. --NicoV ^{(Talk on frwiki)} 14:02, 19 September 2015 (UTC)

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

It would be real nice if I could right align within a table without going to the edit source.

Kcwhbjr (talk) 18:01, 21 September 2015 (UTC)

I added your request to https://phabricator.wikimedia.org/T103276, HTH! --Elitre (WMF) (talk) 18:21, 21 September 2015 (UTC)

Copy/pasting whole sections with Visual Editor is still somewhat of a hassle:

1. Selecting a header and the following section and copy/pasting it somewhere else in the article looses the header format of the first line. This happens with both "Shift + Arrow down" and "Shift + Left Mouse button".
2. Selecting text with "Shift + Arrow down" and "Shift + Left Mouse button" is interrupted sometimes. Take Hockenheim for example, and try to select a text starting at the beginning of the "Town Structure" line down to "History" and further down:

• With "Shift + Arrow down" the selection stops immediately at "Town Structure", I can't select further text.
• With "Shift + Left Mouse Button" further selection is possible, but it then stops at "History". If I try to select more text, the text before "History" and the "History" header is de-selected while I can select further text. Note: this happens only with headers immediately followed by an image. The same function works OK around the "International relations" header further down (with no image nearby).

System specs: Windows XP, FF 40.0.3, Vector skin, desktop version. If you have further questions or the description is unclear, please ping me. GermanJoe (talk) 11:51, 22 September 2015 (UTC)

Hey GermanJoe, good to hear from you again (and thanks for including specs).

1. may be https://phabricator.wikimedia.org/T52126, which I just updated.
2. could be a task I filed a while ago, https://phabricator.wikimedia.org/T75512. --Elitre (WMF) (talk) 14:56, 23 September 2015 (UTC)

Thanks for finding those tasks. I subscribed and added my case to the second task (as another example for possible research). GermanJoe (talk) 15:09, 23 September 2015 (UTC)

ϢereSpielChequers 11:36, 14 September 2015 (UTC)

Hey WereSpielChequers. According to https://phabricator.wikimedia.org/T112286, it will take a couple of days before everything goes back to normal. Thanks for your understanding, --Elitre (WMF) (talk) 17:34, 14 September 2015 (UTC)

OK interesting bug, considering my editing today it makes sense that I'd have edited some pages that hadn't been edited for a few months. I'll drop V/E temporarily and go back to the classic editor for a week. ϢereSpielChequers 18:08, 14 September 2015 (UTC)

Note - this may need a second look. The timeline is not completely clear, but the error has been reported again a few hours ago on help desk (see new info in Phab thread). GermanJoe (talk) 02:53, 24 September 2015 (UTC)

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

URL: https://en.wikipedia.org/wiki/User:Raiseyourvibration?veaction=edit

After I edited, I could not save it: "Something went wrong. parsoidserver-http: HTTP 400."

Raiseyourvibration (talk) 16:32, 11 September 2015 (UTC)

Also getting this error. I am editing using the Edge browser though I was also seeing this error in IE 11. EyeTripleE (talk) 01:54, 14 September 2015 (UTC)

Hello Raiseyourvibration and EyeTripleE. Thank you for stopping by. The issue you're describing is being actively tackled in https://phabricator.wikimedia.org/T112286 . Regards, --Elitre (WMF) (talk) 10:24, 14 September 2015 (UTC)

Still getting this error even though the Phabricator ticket has been resolved. I think this is a separate issue. EyeTripleE (talk) 20:00, 20 September 2015 (UTC)

That task has been reopened. However, looks like not all error messages mentioning Parsoid are actually due to it. --Elitre (WMF) (talk) 13:22, 24 September 2015 (UTC)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12

URL: https://en.wikipedia.org/w/index.php?title=Ka%C3%A7anik_Gorge&veaction=edit...I would need the origianal artical to make sense of this...there are too many missing punctuations and too many literal translations inserted to get the gist of what is going on here. I wowuld only be guessing as to the sense of the article as it presently exists.

JohnHBell (talk) 11:03, 26 September 2015 (UTC)

When the citation's contents are (only) [3], then the contents are invisible in the Re-use dialog and in the context menu. You can see an example at Fruit snack, in the third ref (after "General Mills" in the lead). I can reproduce this in Firefox and Safari on Mac OS 10.10. WhatamIdoing (talk) 00:01, 29 September 2015 (UTC)

Reported at [4], thank you. --Elitre (WMF) (talk) 08:48, 29 September 2015 (UTC)

Hi,

I was using the automatic citation function on Apostolos Gkountoulas. A lot of the pages I was adding were WorldRowing.com results pages. The actual pages are called things like http://www.worldrowing.com/events/2009-world-championships/mens-pair/final/ and have the detail of the event in the title, but the automatic citation gadget reads the title from the website, which is 'event' so they all show up as - Events - worldrowing.com". www.worldrowing.com. Retrieved 2015-09-27.

Is there any way of getting round this or is it a problem with the way the worldrowing website is written? Red Fiona (talk) 23:47, 27 September 2015 (UTC)

Hi there. So what Citoid does there is reading the page metadata, and what you see is the result. However, it should be possible to write some code (aka "translator") to improve the situation. --Elitre (WMF) (talk) 09:02, 29 September 2015 (UTC)

SSastry, User:cscott ISBN are still put between nowiki tags. When will this stop? An example with other damages done by VE:

• Useless abbr tags without parameters
• Useless time tags
• Errorneous links like [[reliquaire]]<nowiki/>s
• Incorrect referencing, maybe a user mistake: <sup>1</sup>

--NicoV ^{(Talk on frwiki)} 15:37, 20 September 2015 (UTC)

Thanks NicoV. All are VE-side issues and I'll point them to this. SSastry (WMF) (talk) 17:43, 21 September 2015 (UTC)

I've filed phab:T113535 for the ISBN issue. Thanks for continuing to uncover these corner cases. C. Scott Ananian (talk) 21:32, 23 September 2015 (UTC)

Unfortunately, they are not corner cases, they happen too frequently. ISBN problems are happening a lot on frwiki, other problems also. I hope ISBN will be fixed ASAP (same also for external links), it's really tiring to see so many incorrect edits. --NicoV ^{(Talk on frwiki)} 21:55, 23 September 2015 (UTC)

C. Scott Ananian I forgot to mention... on frwiki, ISBN appear mainly in 2 places, in references and in list (in bibliography chapters), so the problem with ISBN is very frequent. I've reported other problems directly on phabricator a few days ago, new tickets seem to be simply ignored :-( (phab:T113259, phab:T113176, phab:T113173, phab:T112971, phab:T94712, ...). --NicoV ^{(Talk on frwiki)} 22:01, 23 September 2015 (UTC)

Hey there. Thanks as usual for your reports. I think they've been all addressed recently. I'd like to take the occasion to invite to/remind everyone of the weekly triage meetings (yes, they're still happening!); if for any reason you can't attend one (the next one is in a few hours), please remind us of the issues you'd like to bring up. If you could add them on this page by, say, the day before, that'd be rad. Talk to you soon, --Elitre (WMF) (talk) 17:05, 29 September 2015 (UTC)

Bobologist (talk) 00:30, 20 September 2015 (UTC)

I've had this happen to me when I uploaded something and immediately wanted to insert it. It looked as though the list of available files was not updating quickly enough to provide it to VE for the list. Mike Christie (talk - contribs - library) 20:26, 20 September 2015 (UTC)

Hey Bobologist, as Mike says, sometimes this happens with files which have just been uploaded (so it's a search index issue, not a VE one). As per my test, this is already not the case today with your 2 files. (BTW the ultimate goal with media is, quoting from the VE roadmap, "Editors can upload a file to Commons and use it in the page without leaving the edit, including starting it with "drag-and-drop".) --Elitre (WMF) (talk) 09:35, 21 September 2015 (UTC)

I'm inclined to concur that it is a bug in media searching that favours irrelevant photos over relevants. I too have had trouble adding-in-VE recently uploaded-to-Commons photos. It seems though that they are available but often way way down the list of media search results, well below photos that appear to be irrelevant to the key words being used on search (often my photo will have the exact words of the article title in the photo title so you would expect them to pop up towards the top). I have previously reported similar problems with the suggested wikilink searching (overlooking very obvious matches in favour of very tenuous matches); I don't know if the two are connected. It might be nice if the media search window had a tick box "only search in my photos" to limit the search to uploads by that user, or alternatively prioritise a user's own photos over other uploads as a default behaviour. Kerry (talk) 00:49, 30 September 2015 (UTC)

I'm trying to edit the Reception section from Dismaland. If I cut a word or phrase from some other source and try and paste it in. The whole page scrolls placing the line I've just pasted either as the last line in the screen or just below the bottom of the window. This is very distracting, as I then need to rescan the page to find where I was editing. Google Chrome on a Mac Book. --Salix alba (talk): 16:45, 22 September 2015 (UTC)

Chrome on Windows 8 doesn't do the pasting at the end thing but does do the scrolling thing. Red Fiona (talk) 18:57, 22 September 2015 (UTC)

To avoid any confusion. The data pasted goes in the right place, its just the way things scroll which is most awkward. --Salix alba (talk): 22:08, 22 September 2015 (UTC)

The fix for https://phabricator.wikimedia.org/T89623 should go out this week (I hope that will fix your problem). --Elitre (WMF) (talk) 14:44, 23 September 2015 (UTC)

Resolved

Looks like it works properly now.--Salix alba (talk): 06:37, 1 October 2015 (UTC)

Moving in-text references to another spot in the article has a minor bug in Visual Editor. Take AdPushup (a terrible article, but a good example): see the cite spam in "history", refs 7, 1, 8, 3, 9, 2. Trying to drag and drop reference 3 (with the mouse) somewhere else within this list of references does not work - the dragging is OK but dropping is not possible: the mouse cursor keeps being displayed as stop sign for "action not possible". Dropping the reference is only possible outside the list in the main text, not between 2 other references. It should be possible to drop a reference between 2 complete, correctly defined, reference structures (specs: Windows XP, FF 40.0.3, vector) ==> Actually, dropping of all correctly closed tags should be possible between all correctly closed tags. GermanJoe (talk) 14:19, 30 September 2015 (UTC)

Hey GermanJoe, I was able to drag and drop. The "trick" is you don't keep the cursor over the numbers - that's where the stop sign is displayed. If you put it below the numbers, in FF, you should be able to find the spot where you can drop the ref. For the record, I had difficulties in Chrome as well, but I was able to find the tiiiny space between a ref and the other where dropping is allowed. I should put this into Phab anyway... --Elitre (WMF) (talk) 15:04, 30 September 2015 (UTC)

Targetting the lowest tiny pixel worked, thank you. Maybe the devs can improve that a bit, although the space is limited there of course. GermanJoe (talk) 15:12, 30 September 2015 (UTC)

Let's see what they say at https://phabricator.wikimedia.org/T114355. HTH, --Elitre (WMF) (talk) 11:44, 1 October 2015 (UTC)

I was trying to move the photo of the mill in Wallaville (the version that I was working on) into the History section (positioned on the left because of the infobox). I selected the mill photo (went "blue"), I dragged it up to the History section where a line appears after the heading where I "let go" and drop it. But the photo doesn't move - it stays at the bottom of the page. I did it a number of times without success, so I cheated and looked at the wikitext as I suspected the answer was there. Sure enough, it turned out the photo of the church and then followed by the photo of the mill are at the start of the article and so the repositioning of the mill photo into the history section doesn't alter its positioning relative to the church photo so it remains at the end of the article. So, the only way I could achieve the outcome using the VE was first move the church photo to the bottom of the article, then move the mill photo to the top of the history section and left-position it and then reposition the church photo, but how is the VE user to work that out? I think there needs to be some kind of visual anchoring of the photos just as templates have, so the visual anchors can be reliably dragged-and-dropped to reorder them. Kerry (talk) 00:35, 30 September 2015 (UTC)

As you say, image positioning doesn't really "make sense" in any editor (it's actually above, but then because of the infoboxes it's below... a mess). I'll check Phab when I can and will add your suggestion if nothing similar is already there. Thank you! --Elitre (WMF) (talk) 15:10, 30 September 2015 (UTC)

I put it at https://phabricator.wikimedia.org/T114369 . Hopefully someone will be able to write a better description! --Elitre (WMF) (talk) 14:16, 1 October 2015 (UTC)

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

URL: https://en.wikipedia.org/w/index.php?title=Cuexcomate&veaction=edit&vesection=6

This acticle contains a series of bare html links. Attempting to edit them the first time gives an add label button. Clicking this auto labels them with the url. On attempting to edit again there is no way to change the label.

Phatom87 ^{(talk • contribs)} 18:44, 4 October 2015 (UTC)

There is a way to change the label, but it's not as intuitive as with the "Add label" button (you basically type something in the light blue field, just before the "external link" icon, and then Backspace to remove the old text). The "add label" button is only available when editing bare links (https://phabricator.wikimedia.org/T55973 is still open). However, when you first click on that button, you can overwrite the URL if you want. HTH, --Elitre (WMF) (talk) 12:45, 5 October 2015 (UTC)

In my closed Mediawiki the Visual Editor ist freezing at start of the editing. I can not reproduce that behavior each time, but it happened at 1 of 10 startups. The Console of my firebug shows the following:

TypeError: origin is null ....cloneObject=function(origin){var key,r;r=createObject(origin.constructor.protot... — Preceding unsigned comment added by 194.31.198.71 (talk) 12:19, 5 October 2015 (UTC)

This kind of feedback would be better handled at mediawiki.org, more specifically at mw:Extension talk:VisualEditor, but maybe the product manager for VE can help here as well? --Elitre (WMF) (talk) 12:49, 5 October 2015 (UTC)

121.54.54.220 (talk) 14:20, 5 October 2015 (UTC)

I want visual editor but I. Am a IP address and I can't get account as I prefer to edit via ip please let ip edit using visual editor please — Preceding unsigned comment added by 65.175.243.206 (talk) 23:30, 5 October 2015 (UTC)

See Wikipedia:VisualEditor/User guide#First step: enabling VE. You can click the Edit tab first and then manually change the url from action=edit to veaction=edit. PrimeHunter (talk) 00:19, 6 October 2015 (UTC)

(crossposting from WT:VE)

Hey all,

This is just a quick note to highlight that the location for the visual editor’s preference is about to move – from the "Beta" tab to the "Editing" section of your preferences (as is currently the case on almost all the other WMF wikis; it doesn’t mean the visual editor is complete, or that it is no longer “in beta” though).

This action will not change anything else for editors: it still honours editors’ previous choices about having it on or off; logged-out users will continue to only have access to wikitext; the “Edit” tab will still be after the “Edit source” one.

We don’t expect this to cause any glitches, but in case there are, please let us know here as usual! This should be done in the next few days, and I’ll post a follow-up message then. Best, Elitre (WMF) (talk) 21:37, 30 September 2015 (UTC)

Transition complete

This is now done. You can read a longer note at WT:VE if you’re interested in details. Best, Elitre (WMF) (talk) 15:09, 7 October 2015 (UTC)

Dragging and dropping an image into the start of a definition list shouldn't be so easy to do (or maybe not even possible at all). I think it will be easy to reproduce if you have a ==Section== that starts with ;an association list, and you drag an image into it. I've got a screenshot; ping me if you want me to upload it to a bug report. WhatamIdoing (talk) 23:37, 8 October 2015 (UTC)

My visual editor option has disappeared and went I look in my beta tab, it's no longer listed there as an option. GLG GLG (talk) 15:07, 7 October 2015 (UTC)

Hey GLG GLG, see Wikipedia:VisualEditor/Feedback#The_visual_editor.E2.80.99s_preference_will_be_moving_tabs. Can you confirm you see it in the new location? Best, --Elitre (WMF) (talk) 15:16, 7 October 2015 (UTC)

I do not see it there. But the visual editor option re-appeared when I go to topic mainpages, so I guess things are okay. GLG GLG (talk) 15:20, 7 October 2015 (UTC)

Maybe it wants to play hide and seek with you, GLG GLG :) Let's recap. If you click here, there's a list of checkboxes in the middle of the page. The last one says Temporarily disable the visual editor while it is in beta, and it's unchecked. If this is the case, you're good to go, and happy VEditing! --Elitre (WMF) (talk) 15:23, 7 October 2015 (UTC)

(Also, I'm guessing that maybe you were looking for the visual editor's Edit tab in namespaces where it just isn't enabled yet. --Elitre (WMF) (talk) 15:27, 7 October 2015 (UTC) )

Another possibility is that the preferences page was cached; reloading it could make this new option visible. -- John Broughton (♫♫) 16:50, 7 October 2015 (UTC)

I also had this issue. The box to disable VE was checked by default for me, even though I had previously turned the feature on explicitly. wctaiwan (talk) 04:27, 8 October 2015 (UTC)

Hey wctaiwan, really sorry for the inconvenience. How long ago does "previously" mean in your case? Thanks, --Elitre (WMF) (talk) 10:44, 8 October 2015 (UTC)

I don't really remember, sorry. It would have been on the order of months. (Judging from [5], possibly in February 2015?) I'm pretty sure I did opt out and then back in at some point, though. wctaiwan (talk) 17:46, 8 October 2015 (UTC)

That's ok. Any chance you may have changed any other preference recently? Best, --Elitre (WMF) (talk) 19:38, 8 October 2015 (UTC)

I don't think so. Anyway, I was more concerned that most or all existing editors with VE enabled might have lost it with no obvious indication of why. If this is an isolated issue, I don't think we need to worry about it too much. Thanks. wctaiwan (talk) 21:58, 8 October 2015 (UTC)

Of course, but the change affected everyone at the same time, and here we have just one report (and a half, since we're still not sure about GLG GLG); there can be glitches at this scale, but by now we can probably assume your case is isolated - again, too bad though. Happy VEditing, --Elitre (WMF) (talk) 06:46, 9 October 2015 (UTC)

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

The 'save page' dialog does not appear no matter how many times I click the 'save page' button

My Chemistry romantic (talk) 10:06, 11 October 2015 (UTC)

Please, fix VE, single nowiki tags were already bad enough, but piling them up uselessly is even worse... 3 nowiki tags in a row <nowiki/><nowiki/><nowiki/>. I don't even mention the many other edits on this article were damaging nowiki tags were added by VE. --NicoV ^{(Talk on frwiki)} 21:22, 12 October 2015 (UTC)

User:SSastry (WMF), can you take a look at this diff?

I'm not sure whether this is VisualEditor or Parsoid (or both). Whatamidoing (WMF) (talk) 17:39, 15 October 2015 (UTC)

Probably Parsoid. This week we are on an offsite, so something we'll pick up next week. SSastry (WMF) (talk) 20:15, 15 October 2015 (UTC)

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

I am trying to edit the article 2015 Southeast Asian haze and more than half the article is displayed under the 'References' section. The text is displayed as wikitext while the tables are shown as they would be displayed in VisualEditor. My Chemistry romantic (talk) 03:39, 11 October 2015 (UTC)

I'm not seeing that using the latest versions of Firefox and Chrome (Mac OS). (@My Chemistry romantic: Your operating system, Windows NT 6.1, comes in three variants, including Windows 7. Which one are you using?) -- John Broughton (♫♫) 16:34, 11 October 2015 (UTC)

This bug, and the bug below, were fixed with this edit. --151.42.57.178 (talk) 09:35, 12 October 2015 (UTC)

I wonder how common that problem is (invalid quotation marks on ref tags). It's something that ought to be identifiable with a script like WP:AWB. Whatamidoing (WMF) (talk) 17:31, 15 October 2015 (UTC)

I've posted a request for assistance at Wikipedia:AutoWikiBrowser/Tasks#Invalid quotation marks on ref tags. -- John Broughton (♫♫) 20:40, 15 October 2015 (UTC)

Dominikmatus (talk) 13:38, 9 October 2015 (UTC)

Hi Dominikmatus, is this problem still happening?

I don't have that problem in Safari on my Mac, but perhaps it affects only Chrome or Windows 7, or perhaps they have already fixed it. Whatamidoing (WMF) (talk) 17:36, 15 October 2015 (UTC)

It's already not happening. Even not with cite popup. :) Dominikmatus (talk) 10:27, 16 October 2015 (UTC)

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

URL: https://en.wikipedia.org/wiki/List_of_bus_routes_in_Perth,_Western_Australia?veaction=edit

When I am in editing view, the bullet points for route 98 seems to have extra space above and below it..

102 at 1625 (talk) 13:12, 16 October 2015 (UTC)

I think it's because Template:Transperth bus route/operator name doesn't include those route numbers. The list formatting is correct, but the 98 and 99 routes have an extra-tall, un-colored box at the start. Whatamidoing (WMF) (talk) 17:29, 16 October 2015 (UTC)

But I'm finding that sometimes when I leave an edit page open for a long time (> 15 minutes), I am sometimes logged out mid-edit and therefore have to save as an IP or lose the changes I've made. I'm not sure why it logs me out. Red Fiona (talk) 12:48, 14 October 2015 (UTC)

Red Fiona, how long has this been going on? Just this week, or multiple weeks? Whatamidoing (WMF) (talk) 17:41, 15 October 2015 (UTC)

I'd say a month at least. The only reason I mentioned it this time is that I was in the middle of a big addition (I'm me and the most recent IP editor here - https://en.wikipedia.org/w/index.php?title=Alexandre_Charpentier&action=history) when it happened. — Preceding unsigned comment added by Redfiona99 (talk • contribs) 18:05, 15 October 2015 (UTC)

Then I think we can rule out the two problems that Ops has been dealing with this week as the cause.  ;-)

Have you also encountered this problem in the wikitext editor? Getting logged out isn't supposed to be a VisualEditor thing (which IMO isn't proof that it isn't in this case, just that it is less likely than some other possibilities). Whatamidoing (WMF) (talk) 21:22, 16 October 2015 (UTC)

I don't recall having encountered this bug in text-editor but I shall do a dummy run in a draft article. Red Fiona (talk) 14:41, 18 October 2015 (UTC)

I am having troubles inserting Worldcat refs in Visual Editor (ex: https://www.worldcat.org/title/pieter-bruegel/oclc/49531157&referer=brief_results). There seem to be a bug with the import of ISBN-10 and 13 from Worldcat.

Visual Editor (citoid?) seems to import 13 characters for a ISBN-10, leading to an error after import. (for ex. Roberts-Jones, Philippe; Roberts-Jones, Françoise (2002-01-01). Pieter Bruegel. New York: Harry N. Abrams. ISBN 0810935317 97 Check |isbn= value (help).) When IBSN-13 is also imported (though not in ENwiki), the import leads to a 12 characters(?) import for an ISBN-13. In my example in FRwiki, you would get "(en) Philippe Roberts-Jones et Françoise Roberts-Jones, Pieter Bruegel, Harry N. Abrams,1er janvier 2002 (ISBN 0810935317 97[à vérifier : ISBN invalide] et 8081093531[à vérifier : ISBN invalide], lire en ligne)"

This should have led to ENwiki: Philippe Roberts-Jones (1 November 2002). Pieter Bruegel. Harry N. Abrams. ISBN 978-0-8109-3531-0.

When using Visual Editor on FRwiki, one would get the following code generated ((Ouvrage|langue = English|prénom1 = Philippe|nom1 = Roberts-Jones|prénom2 = Françoise|nom2 = Roberts-Jones|titre = Pieter Bruegel|éditeur = Harry N. Abrams|date = 2002-01-01|isbn = 0810935317 97|isbn2 = 8081093531|lire en ligne = https://www.worldcat.org/title/pieter-bruegel/oclc/49531157&referer=brief_results|consulté le = 2015-10-18)) instead of ((Ouvrage|langue = English|prénom1 = Philippe|nom1 = Roberts-Jones|prénom2 = Françoise|nom2 = Roberts-Jones|titre = Pieter Bruegel|éditeur = Harry N. Abrams|date = 2002-01-01|isbn = 0810935317 |isbn2 = 9780810935310|lire en ligne = https://www.worldcat.org/title/pieter-bruegel/oclc/49531157&referer=brief_results|consulté le = 2015-10-18)).

I tried through Citoid public API for double checking and it lead to the same problem with the import(https://citoid.wikimedia.org/api?format=mediawiki&search=https://www.worldcat.org/title/pieter-bruegel/oclc/49531157&referer=brief_results) and I get the following (shortened version): [{"itemType":"book","notes":[],"tags":[],"libraryCatalog":"Open WorldCat","language":"English","title":"Pieter Bruegel","publisher":"Harry N. Abrams","place":"New York","date":"2002-01-01","ISBN":["0810935317 97","8081093531"],"abstractNote":"\" [...] .\"--Jacket.","url":"https://www.worldcat.org/title/pieter-bruegel/oclc/49531157","accessDate":"2015-10-18","author":[["Philippe","Roberts-Jones"],["Françoise","Roberts-Jones"]]}]

Thanks for taking the time to consider this Afernand74 (talk) 18:49, 18 October 2015 (UTC)

Thanks for this very detailed message, Afernand74. I've filed this as phab: T116056. Whatamidoing (WMF) (talk) 17:58, 20 October 2015 (UTC)

I just noticed the improved link-editing interface, making it clear (and easy to change) which part of the text will be part of the link or not.

One issue I have is that when typing a search term, a large drop-down list appears. This automatically scrolls the screen far down, to the point where the "Done" button is obscured by the editing menu. In fact, at first I could not figure out how to save the changes at all, until I noticed the "Done" button. (Windows 7, Firefox, Vector) -- Ypnypn (talk) 20:56, 20 October 2015 (UTC)

Thanks for the note, Ypnypn. I'll pass along the compliments.

I'll have to ask whether scrolling the screen is intentional. I think it's "bug" rather than "feature", but I'm not sure. Whatamidoing (WMF) (talk) 16:31, 21 October 2015 (UTC)

The answer is that scrolling is intentional, but scrolling off the screen isn't intentional. It's on the list. Thanks for letting them know. Whatamidoing (WMF) (talk) 20:59, 21 October 2015 (UTC)

When a table end |} is missing, and VE has no clue where the table should really end, it shouldn't add it at random, especially at a place that is obviously a mistake... --NicoV ^{(Talk on frwiki)} 13:48, 23 October 2015 (UTC)

Please, stop VE from adding a useless "link" attribute to the image itself [[Fichier:Euphydryas_editha_5679.JPG|link=https://fr.wikipedia.org/wiki/Fichier:Euphydryas_editha_5679.JPG|thumb|''Euphydryas editha'']]. --NicoV ^{(Talk on frwiki)} 21:27, 12 October 2015 (UTC)

NicoV, have you been seeing a lot of this, or just this one? Whatamidoing (WMF) (talk) 17:44, 15 October 2015 (UTC)

Whatamidoing (WMF) I've seen several articles with this kind of problems, but I haven't checked if it was coming from VE edits. This kind of links has been very recently added to the detection #90 (Internal link written as an external link) of Check Wiki project (current list for frwiki, enwiki). --NicoV ^{(Talk on frwiki)} 18:21, 15 October 2015 (UTC)

It's seems to be an old problem, example from 6 months ago. --NicoV ^{(Talk on frwiki)} 18:56, 15 October 2015 (UTC)

3rd example, really seems to be a VE issue. --NicoV ^{(Talk on frwiki)} 19:10, 15 October 2015 (UTC)

4th example --NicoV ^{(Talk on frwiki)} 19:13, 15 October 2015 (UTC)

5th example --NicoV ^{(Talk on frwiki)} 19:15, 15 October 2015 (UTC)

It's come up a few times before on new images, but the link from this week is an image that (I think) was copied and pasted from a different part of the article, and the others are about adding new images. I think this is a separate problem. I told the product manager about it first thing this morning. He says that what they really need is a set of reliable steps to produce the error. Without that, they can't prove that their fix is actually working. Whatamidoing (WMF) (talk) 18:53, 16 October 2015 (UTC)

new example, VE is continuing to produce garbage on a daily basis (see my other posts below). --NicoV ^{(Talk on frwiki)} 09:08, 24 October 2015 (UTC)

Looks like Citoid has trouble interpreting language code information, I just noticed this behaviour in several articles with Indian sources. See for example [6]. In "Travel Challenges" the last sentence is "Recently, GoUNESCO has started organising fun runs at World Heritage Sites including Hampi,[9], Bidar,[10], Warangal,[11], and Ooty,[12]". Using any of the URLs in the 4 references (I already converted them) to create an automatic citation with Citoid, Citoid reports a language of "en-IN" (example URL #9: [7]). Now that's technically correct of course, but as an English variant such values make little sense to report on the English Wikipedia, and may better be omitted for Citoid usage. And even if they are not omitted, it would be better to "translate" those codes into their readable standard language names. This is not really a bug, but somewhere between URL -> Citoid -> citation template, the handling of language codes and language variants could use another look. (specs as always: Win XP, FF 40.0.3, vector skin) PS: According to Template:cite web the template (and all other CS1 templates probably) only accept ISO 639-1 codes or just "English" (or nothing) in this example. Disclaimer: I don't know the technical background there, you may need to contact someone more knowledgeable in the coding and logic for CS1. GermanJoe (talk) 15:54, 17 October 2015 (UTC)

Seems like something that should be fixed in VE or CS1. More accurate data is always good, if we choose not to represent that, then we should ignore it during display, and not during entry of the information in my opinion. —TheDJ (talk • contribs) 07:19, 19 October 2015 (UTC)

@TheDJ: In general I agree of course, especially with your "more data is always good" argument. However, it's probably worth checking first, how exactly Citoid is supposed to handle language-code information - just to avoid misunderstandings, before some of the most-used en-Wiki templates are changed. I have left a notification at the central CS1 help forum now to inform other interested editors. GermanJoe (talk) 14:32, 19 October 2015 (UTC)

"en-IN" or any other "en-XX" should be truncated to (or not expanded from) "en" in Citoid/VE to be used in the cite templates.

I don't know where "en-IN" would have come from in the example URL #9 above. I looked at the HTML source, and it says xml:lang="en" lang="en". The article is clearly written in English. – Jonesey95 (talk) 16:30, 19 October 2015 (UTC)

I'm thinking that it would be better to change the template (to suppress all the en variants from display) than to provide less meta data. Whatamidoing (WMF) (talk) 17:00, 20 October 2015 (UTC)

@Whatamidoing (WMF): After some searching in the MediaWiki forums, there is actually a Phab task (see box) for a similar question (from it-Wiki), but the thread is quite new. So it isn't clear yet, if any improvements are planned (and if yes, which ones exactly). GermanJoe (talk) 22:01, 20 October 2015 (UTC)

CS1 module talk has an archived discussion from April about handling the language parameter, especially when the reported source language is the Wiki's own language. Just linking to provide some background details, if needed. GermanJoe (talk) 12:26, 21 October 2015 (UTC)

I looked at one of the Italian examples, and there's a bit in the HTML that says "lang=it_it". I wonder if that was being picked up and overriding the actual language setting (which is plain "it"). Whatamidoing (WMF) (talk) 19:43, 26 October 2015 (UTC)

User agent: Mozilla/5.0 (iPad; CPU OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1

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

3rdpartybia (talk) 18:53, 28 October 2015 (UTC)

@3rdpartybia: It's not at all clear why you posted here. Are you having a problem with VisualEditor? Please explain. -- John Broughton (♫♫) 17:43, 29 October 2015 (UTC)

I was adding ((According to whom)) to an article and the blurb at the top was exactly like this:

((GENDER:$3|You are adding)) the "$1" template to this page. It doesn't yet have a description, but there might be some information on the <a $2>template's page</a>.

So there is something not rendering as designed here. I can supply a screenshot if required. — Martin (MSGJ · talk) 14:03, 30 October 2015 (UTC)

Added here here. Thanks a lot for reporting, --Elitre (WMF) (talk) 14:08, 30 October 2015 (UTC)

See User:99of9/sandbox3#Test_5 --99of9 (talk) 02:59, 29 October 2015 (UTC)

@99of9: Yes, that's a known bug. One (kludgy) workaround is to apply additional formatting to the text in question - so, if you pasted some bolded text, then italicize it. After that, you can remove all formatting. (And no, I don't know, off-hand, when the VE team plans to fix this.) -- John Broughton (♫♫) 17:50, 29 October 2015 (UTC)

99of9, does this work if you copy it from any Wikipedia article, or have you encountered this from other websites?

I talked to the relevant dev about this earlier this week. His current work will probably fix it. Whatamidoing (WMF) (talk) 00:19, 30 October 2015 (UTC)

I don't usually copy from other websites, so I don't know. If sometime I encounter a problem I'll post here. --99of9 (talk)

Thanks, I appreciate it. Whatamidoing (WMF) (talk) 18:30, 30 October 2015 (UTC)

See this edit by USer:JaJaWa that shows multiple problems with VE:

• Title with h3 tags instead of wiki syntax
• Table is partly in wiki syntax, partly in HTML syntax
• Bolding is in HTML syntax, even with a xml:lang attribute (?) and a strange value
• Strange href in the middle of the table

--NicoV ^{(Talk on frwiki)} 07:43, 24 October 2015 (UTC)

Similar problems on frwiki. --NicoV ^{(Talk on frwiki)} 07:45, 24 October 2015 (UTC)

Other example on enwiki. --NicoV ^{(Talk on frwiki)} 08:16, 24 October 2015 (UTC)

The table layout was copied from the page on FR wiki - apologies if this has caused issues.   JaJaWa |talk  16:18, 25 October 2015 (UTC)

Hello, JaJaWa. Thanks for your note. Could you give me a URL to the page, where you copied the table layout from? It would be really helpful. Whatamidoing (WMF) (talk) 19:48, 26 October 2015 (UTC)

Yes, it's just the equivalent page to the one I edited, FR wiki - Chimelong Paradise. Also I possibly had Google Translate running on top!   JaJaWa |talk  03:34, 27 October 2015 (UTC)

Chrome on Windows? Which version?

I'll ask for the current status, but I believe that VisualEditor and Chrome's built-in translation were not good friends. That might be the entire problem. Whatamidoing (WMF) (talk) 22:13, 27 October 2015 (UTC)

It would have been Chrome for Mac with the built in translator, or Safari for Mac, with an extension.   JaJaWa |talk  06:06, 31 October 2015 (UTC)

—Granger (talk · contribs) 22:53, 2 November 2015 (UTC)

If they is being done by VE we need to shut it down until it is fixed.

In this edit [8]

All these hard spaces have been added [9] Doc James (talk · contribs · email) 02:19, 4 November 2015 (UTC)

Fixed in this edit [10] Doc James (talk · contribs · email) 02:21, 4 November 2015 (UTC)

Are you sure they're hard spaces? And did you notice that it was replacing the link formatting? There used to be a lot of links in the lead, and now there are none. I have some ideas about what this might relate to. If my guess is right, then the editor is using Internet Explorer. I'll need to go find the old thread first to see whether it's really a match. Whatamidoing (WMF) (talk) 07:47, 4 November 2015 (UTC)

I like the VisualEditor a lot. Occasionally, I'd like to be able to switch to source editing to do some specific work and then switch back to visual editing. I know how to do the former, but then I've not been able to figure out how to get the VisualEditor back. --RaymondYee (talk) 14:48, 25 October 2015 (UTC)

Hello, RaymondYee. Thanks for your question. The answer is: This isn't currently possible, but it will be possible soon, maybe as soon as next Thursday (05 November). Whatamidoing (WMF) (talk) 19:49, 26 October 2015 (UTC)

Thanks, Whatamidoing (WMF), for your answer. Is there some place to track when this future will be launched, other than look at the VisualEditor after Nov 5? RaymondYee (talk) 03:20, 28 October 2015 (UTC)

RaymondYee, the main task is at phab:T49779, but since it's already at patch-to-review state, then checking back after the usual deployment train next Thursday (around noon in California) may be the simplest. It may also be posted at m:Tech/News/Next. Whatamidoing (WMF) (talk) 18:48, 28 October 2015 (UTC)

@Whatamidoing (WMF): I think I saw somewhere that the process to go from the wikitext editor to VE is to click on the "Edit" tab. That assumes, of course, that the user has two tabs, "Edit" and "Edit source". What if he/she doesn't? (For example, the user starts VE with a shortcut key, when desired.) -- John Broughton (♫♫) 00:04, 31 October 2015 (UTC)

They are aware of at least some of the issues related to having only one edit tab. I'm hoping that we'll be able to test your particular case soon. Whatamidoing (WMF) (talk) 07:49, 4 November 2015 (UTC)

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

I added Red5 content to the page below but for some reason the text in the first column is centered throughout the edit whereas the existing content is aligned to the left. Is there a way to fix this? URL: https://en.wikipedia.org/wiki/Comparison_of_streaming_media_systems?veaction=edit

JamesMaynard (talk) 21:23, 5 November 2015 (UTC)

Hi JamesMaynard,

Thanks for aksing about this. That table sets the formatting for the whole table: class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%;". The "text-align:center" part says that the contents of all table cells should be centered. The right-aligned cells have been individually and manually set to right-alignment, via the ((rh)) template (which only adds that long string of gobbledegook again, this time for the individual cell only, but it's quicker to type). VisualEditor does not support changing the formatting of individual table cells. Therefore, this cannot be done in VisualEditor at this time.

Looking at the article history, I saw several changes in close succession. Did you ever get a warning about an WP:Edit conflict when you saved the page? Whatamidoing (WMF) (talk) 16:27, 6 November 2015 (UTC)

The visualeditor reference names of ":0" and the like are causing problems for User:AnomieBOT, which has a routine that fixes orphaned references. Because of the thousands and thousands of references named ":0", Anomie had to edit their bot to ignore visual editor references, meaning that orphaned references created by visualeditor will not be fixed. The refnames used by Visualeditor need to be unique to avoid this problem. Perhaps the software could maintain a counter and name them "VE1" "VE2" "VE3", and have unique names for each references even on different pages. Oiyarbepsy (talk) 06:16, 5 November 2015 (UTC)

Discussed here, in general: Wikipedia:VisualEditor/Feedback/Archive 2013 7#Naming references after first creation

As was pointed out in one of these tracked issues, VE's simple-minded reference naming will inevitably cause problems when text with footnote(s) is copied from one article to another, because a named reference without footnote text could well end up conected [incorrectly]] to an existing, identically numbered citation. And if a named reference with footnote text is copied, there is now a significantly increased probability - because of VE naming - that there will be two citations with the same name.

A slightly more complicated VE naming approach (start with (1) last name; if no such field, then (2) first word in publisher field; if no such field, then (3) first two words in title; if no such field, then last ten characters of the URL, removing any special characters; then, if still a collision, add [concatenate] "1"; if still a collision, add "2" instead of "1", etc) would minimize collisions. Still, the best approach would be to either (a) rename ref=name collisions when a citation is pasted into a page, or (b) warn the user about the collision at the time of pasting.

Am I correct in saying that if a problem does occur with reference naming, it's not possible to fix in VE because VE lacks functionality to let users change reference names?

And finally - here's another task that is related, though apparently transient:

Tracked in Phabricator
Task T94712

-- John Broughton (♫♫) 20:19, 5 November 2015 (UTC)

VisualEditor doesn't retain the ref name when you copy a citation across articles.

VisualEditor no longer has the tools to set manual ref names. You can, however, easily remove the named ref (the <ref name="Wrong One" />) and replace it with the correct one. As far as the wikitext parser is concerned, that's what you're actually doing when you change the ref name.

I am definitely pro-sensible naming and pro-manual naming as well. I'm not sure that a string of numbers is entirely "sensible", though. Also, if each re-used ref (within an article) gets a new number, then we'll end up with refs that actually do match across articles, but that have different ref names. I'd much prefer that they used a ref name based on the contents of the citation template (assuming that a citation template is being used).

As a side note, I see that Chad, Thoroughbred, Japan, Bob Dylan, Ernest Hemingway and many more have a ref that is named (exact/case-sensitive) "NYT". My back-of-the-envelope calculation is that there are 2,000 such refs with that particular name on the English Wikipedia. It looks like there may be a similar number for "name=book", and more than 100 each for name=org, name=web, and name=Lee. User:Anomie might want to set the logic to exclude any ref name with three or fewer characters, no matter what the characters are, and blacklist name="book". Whatamidoing (WMF) (talk) 17:02, 6 November 2015 (UTC)

Since Friday 6 November I have seen six reports from VE users that they just keep being asked for captchas:

1. Wikipedia:Help desk#Editing Fairfield Presbuyterian Church
2. Wikipedia:Teahouse/Questions#How do I save my changes to the article?
3. Wikipedia:Help desk#Having issues SAVING page after making minor changes
4. Wikipedia:Help desk#CAPTHCA malfunction
5. Wikipedia:Help desk#CAPTCHA doesn't work
6. Wikipedia:Help desk#VisualEditor Sandbox Save

PrimeHunter (talk) 06:27, 8 November 2015 (UTC)

@PrimeHunter: This should now be fixed (phab:T118052). Much thanks for the compilation. Quiddity (WMF) (talk) 20:47, 8 November 2015 (UTC)

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

URL: https://en.wikipedia.org/wiki/Nic_Marks?veaction=edit

It won't let me save my changes - I'm stuck in a captcha loop

Stolenchild66 (talk) 20:40, 8 November 2015 (UTC)

@Stolenchild66: Thanks for the bug report. This should now be fixed. Quiddity (WMF) (talk) 20:53, 8 November 2015 (UTC)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:41.0) Gecko/20100101 Firefox/41.0

URL: https://en.wikipedia.org/w/index.php?title=User:Ukulelle/sandbox&veaction=edit&vesection=4

Markdarryl (talk) 01:35, 8 November 2015 (UTC)

Works for me. Could you try again, to make sure that it wasn't a one-time glitch? Whatamidoing (WMF) (talk) 23:22, 9 November 2015 (UTC)

Kerry (talk) 07:25, 8 November 2015 (UTC)

Thanks. I hope that this will be fixed soon. Whatamidoing (WMF) (talk) 23:42, 9 November 2015 (UTC)

Update: Code is written and will be deployed this week. Whatamidoing (WMF) (talk) 00:24, 10 November 2015 (UTC)

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	Add a link to Alison Cerutti from Martins Plavins.
Steps to Reproduce:	I was updating the text on Martins Plavins and wanted to add a link to Alison Cerutti. I did what I normally did, which is select the text by mouse and then going up to the link button in the toolbar. Because I'd only put Cerutti's surname, he didn't come up, which was expected behaviour. I therefore type his full name in and saw that an article did indeed exist for that player ( ). However, when I select that link it only gives a redlink . I did the same thing for Reinder Nummerdor and Richard Schuil just after so it's not a repeatable issue.
Results:	Gave a red link
Expectations:	Links properly to Alison Cerutti.
Page where the issue occurs	Martins Plavins
Web browser	Chrome 46.0.2490.80
Operating system	Windows 10
Skin	Vector
Notes:	Any additional information. Can you provide a screenshot, if relevant?
Workaround or suggested solution	I opened the page in source editor, saw that it had linked properly and saved. Opened Martins Plavins in a new tab and it worked fine.

Red Fiona (talk) 04:04, 8 November 2015 (UTC)

I believe that this happens when the search engine is being a little slow. VisualEditor only "knows" what the search engine tells it about links. Whatamidoing (WMF) (talk) 23:36, 9 November 2015 (UTC)

Thanks, that makes sense. I'll try to be more patient in future :) Red Fiona (talk) 05:37, 10 November 2015 (UTC)

When I opened the VE interface to start editing Elizabeth Palmer, there were suddenly two large flashing blue dots under the link and cite points. What in heaven's name is that about? Risker (talk) 02:57, 6 November 2015 (UTC)

What I saw (elsewhere) were two slowly flashing dots, and not particularly large ones. But yes, odd. I have both a screen shot and a video. -- John Broughton (♫♫) 05:06, 6 November 2015 (UTC)

Try clicking on them, and see what happens.  :-)

You might want to subscribe to the newsletter, which covers recent and upcoming changes like this.

Last week's newsletter also mentions a new feature that reached the Wikipedias less than 24 hours ago, and I'd really like your POV on it. As John noted in a section above, it's now possible to switch back and forth between VisualEditor and the wikitext editor. You can do this multiple times in the same session. Can you figure out how to do it (without someone telling you, that is)? Whatamidoing (WMF) (talk) 16:33, 6 November 2015 (UTC)

Well, the point is that they were annoying and distracting when I didn't want to do anything with the links or citations in the article. On many other websites, when you click on those kinds of distractions, you wind up on a different page instead of where you started, so I was not inclined at all to click on them, quite the opposite. It feels like clickbait. If I have a chance to putter around in content in the next few days, I'll try the switchback - I've accidentally clicked "EDIT" before when I meant to "EDIT SOURCE" and have just clicked "EDIT SOURCE" to switch, but that's not included situations where I've been in the middle of a session. Honestly, I shouldn't have to need to read the newsletter to know what those dots are for, they should be obvious to the editor. Risker (talk) 16:52, 6 November 2015 (UTC)

• Okay, so I went and clicked on the flashing blue dots, and guess what happened? Nothing. At least nothing that didn't happen before those blue dots were there. In other words, they're not doing anything other than being annoying. I have to ask...does the person/team that came up with this idea actually edit Wikipedia articles? I think you need some actual editors pointing out what's useful and what's just design geekery. (Standard info: Win7, FF41.0.2) Risker (talk) 05:08, 7 November 2015 (UTC)

  Thanks for the report. It's phab:T118219 now.

  I don't know who came up with the design. Whatamidoing (WMF) (talk) 23:20, 9 November 2015 (UTC)

I'd call them "beacons"; regardless, they are not a standard icon/feature/approach on any software or web page that I'm aware of, and appear to violate the Principle of least astonishment. If these two are really important, then a blue, circled "i" (as in "information), not changing intensity, is a much better choice.

Why is this important? Because at least some percentage of potential editors are going to think that something is wrong; many of them are not going to click on the beacons to see what they mean, but rather will just close the page to get rid of the "weird things". And as for experienced editors, these beacons are going to be another indication that the VE developers just don't understand user design - something we don't need if we want to convince experienced editors that VE has significantly matured. -- John Broughton (♫♫) 23:17, 8 November 2015 (UTC)

• I did some work tonight with Krenair (thanks for taking the time, Krenair!) and we worked out that there were a few things happening. First, it appears that my anti-virus software (Kaspersky) was blocking the popups that should come from the blue dots. I did a bunch of tweaking with that and with the browser, and eventually found a combination that allowed the popups. I don't think I'll leave things at these settings, though; they're less protective than the "factory settings" and in just the few hours since I did that I've had quite a bit more spam and other junk showing up. I also haven't had any problems with other popups on Wikipedia, which were able to show up through the AV software, so it is odd that these particular ones got caught. But, and this is an important but...even with all that, clicking on the blue dots did nothing for me. However, clicking on the actual link symbol or the word "cite" resulted in a popup. The popups had a brief bit of text describing that one can make links to internal or external web pages, or that citations improve your content. Neither described how to use the button, though, and I needed to click "Okay, got it" to dismiss the popup. I could, however, edit with the popups in place, just as long as I didn't want to edit anything that was covered by them. These were also pretty big popups and most of the space seemed to be taken up by images that weren't great illustrations, but I realise this is an early iteration. (I won't even go into my usual tirade about live content production being not the right place for alpha testing.) But this needs a lot of work. And the flashing dots still don't do anything, the popup is actually on the button. Note: I'll copy-paste this over to the phab task so it's there too. Risker (talk) 06:45, 10 November 2015 (UTC)

Is there supposed to be a limit to then number of times, within a single editing session, that a user can switch between VE and the wikitext editor? I ask because in doing a test, I found that after a couple of switches, I could no longer get from the wikitext editor to VE by clicking on the "Edit" tab. -- John Broughton (♫♫) 20:49, 5 November 2015 (UTC)

John, I did a series of six full cycles yesterday, with no problem. I'm not aware of any hard limit, but I can ask. Whatamidoing (WMF) (talk) 16:12, 6 November 2015 (UTC)

I certainly didn't do six cycles. I'd try again, noting exactly what I did, and post here with my results. -- John Broughton (♫♫) 20:01, 6 November 2015 (UTC)

Reply from the team: There's no actual limit. However, there are a couple of bugs. So if it stops, then you probably hit one of the bugs. Whatamidoing (WMF) (talk) 17:40, 11 November 2015 (UTC)

I've a odd problem. If I start editing and article with the wikitext editor, then switch to the visual editor and save the page. The displayed page title will be "Editing ....". To be precise

1. Start editing a page with the wikitext editor. Say the page User:Sandbox edit link. The main heading at the top of the page will be Editing User:Sandbox.
2. Now switch to VE, using the tab. The main heading will not be changed.
3. Make and edit and save. This does not change the main heading it is still Editing User:Sandbox.
4. Reloading the page sets the title back to normal.

Note it also temporarily changes the <title>...</title> tag, of the page.

Not a great bug, but it did lead to some confusion. After editing a page I switched to another tab, then looked backed at the old tab, which was still saying Editing ..... This confused be for a bit as I thought I had finished editing the page but the page title was indicating I had not. --Salix alba (talk): 10:09, 10 November 2015 (UTC)

Thanks. I can reproduce this in Safari 9/Mac 10.10. Whatamidoing (WMF) (talk) 17:48, 11 November 2015 (UTC)

Try adding a link to ionic compound (click the link button before you have written the words). Like here Ionic compound. In the link box, type "ionic compound" (all lowercase). It gives you two options to link to, the lowercase "ionic compound" and the capitalized "Ionic compound". Click to choose the lowercase one. In goes the link, but its always capitalized and you then have to go back into the word and edit it. It should give you the capitalization you chose. 99of9 (talk) 12:44, 10 November 2015 (UTC)

It's taking the capitalization from the search engine, which always capitalizes. The suggestion is now phab:T118408. Whatamidoing (WMF) (talk) 18:04, 11 November 2015 (UTC)

Visual Editor opt in does not appear despite being logged in.

Mieczkowski (talk) 20:13, 13 November 2015 (UTC)

Hi Mieczkowski,

Go to Special:Preferences#mw-prefsection-editing and enable VisualEditor. It's the last item in a long-ish list, "Temporarily disable the visual editor while it is in beta". Whatamidoing (WMF) (talk) 02:24, 16 November 2015 (UTC)

When will Citoid be able to take an ISBN and generate a citation? I ask because this functionality has been available for many years, elsewhere: OttoBib generates citations, when an ISBN is entered; the output can be set to be in Wikipedia format. -- John Broughton (♫♫) 03:08, 12 November 2015 (UTC)

Here there be dragons, or at least lawyers. On the tech side, it should be pretty straightforward at this point, but their ideal database (which might offer more than just ISBNs) requires a contract, which means that it requires lawyers. Whatamidoing (WMF) (talk) 02:21, 16 November 2015 (UTC)

phab:T108521 might be related ? —TheDJ (talk • contribs) 10:00, 16 November 2015 (UTC)

Yes, it is.

I just added this to T108521, because while OttoBib appears proprietary, there are alternatives:

Can we be more specific? A quick Google search (generate citation from ISBN) shows a number of tools that generate citations from a database; in at least one case, that's WorldCat, via its API (https://www.worldcat.org/affiliate/tools?atype=wcapi ). Maybe it takes a lawyer to negotiate the price, but it's perhaps calling this "Epic" is a bit of an overstatement - it looks like other organizations have done so, and - given that at least one appears to have as its business model getting revenues from online ads - perhaps the price is quite reasonable?

And, hopefully, once an API is available, that's 90% of the solution.

-- John Broughton (♫♫) 17:25, 17 November 2015 (UTC)

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

URL: https://en.wikipedia.org/w/index.php?title=List_of_anime_conventions&veaction=edit&vesection=1ted in 2012

Anime Fusion Bloomington, Minnesota Held in October Started in 2012

Lawbunnie007 (talk) 21:00, 16 November 2015 (UTC)

I have copied your comment to a more relevant page. You can see it at Talk:List of anime conventions#Missing Convention. Whatamidoing (WMF) (talk) 18:34, 17 November 2015 (UTC)

To reproduce, try opening this revision of the November 2015 Paris attacks page with the VisualEditor. The page looks fine until the "Attacks" subsection, at which point raw wikitext becomes visible, starting with the text

((quote box↵|title=Timeline of attacks↵|align=left↵|width=25%↵|quote=↵13 November

and then most of the rest of the page following that is lost. It's been some time since I've seen the VE break on a high-profile page like this. Browser: Firefox 42 on Debian Linux 8, on x86-64. Also verified with Firefox 42, and Safari, on MacOS X El Capitan. -- The Anome (talk) 11:11, 15 November 2015 (UTC)

The problem is with the invalid wikitext: <ref name="reuterstimeline /> contains unpaird quotation marks. The wikitext has been corrected since then. Whatamidoing (WMF) (talk) 02:22, 16 November 2015 (UTC)

Since that rev displays OK, despite the bad wikitext, can VE parse the wikitext in the same way the display code does, to avoid having large amounts of page text disappear in vedit mode? Mike Christie (talk - contribs - library) 02:32, 16 November 2015 (UTC)

Agreed. The "invalid" wikitext is not the problem here. What is and isn't valid in wikitext is a moot point: the only real spec for wikitext is the behavior of the mainline wikitext parser, which is defined by implementation, not any formal spec. For this reason, the VE's parser is intended to mimic the behaviour of wikitext processing, quirks and all. Here it doesn't, and things break because of it. Bringing this to the attention of the Parsoid team so they can fix it, in order to make the VE more reliable so that it can be deployed more widely without breaking the encyclopedia, is the exact and entire point of reporting this bug. What's the point in us filing bugs here if they are just going to be ignored? -- The Anome (talk) 08:03, 16 November 2015 (UTC)

"The problem is with the invalid wikitext" does not mean "this is just going to be ignored". Identifying the trigger for a bug is generally a necessary precondition for fixing it, and as the dev notes below, this bug report has indeed been fixed.

However, when you are next faced with a decision about whether to argue in favor of maintaining bug-for-bug compatibility between VisualEditor and the current state of the various pieces of "the parser", you may want to keep in mind that the parser itself is being replaced (e.g., phab:T89331). This means that invalid wikitext that (sort of) works today will not necessarily work in the future. Whatamidoing (WMF) (talk) 18:30, 17 November 2015 (UTC)

You are still faced with the bug-for-bug compatibility problem in one form or another, because you have a massive corpus of text that you need to maintain backward compatibility with one way or another. Removing HTML Tidy is a good thing, but every ambiguity in the syntax or implementation is still something that requires a human decision to resolve. This should have been obvious from the start of the project: getting to 80% working was quick and easy, it's getting to 100% (or even to 99.9%) that's asymptotically difficult.

I don't envy the VE team's task, as I have some understanding of the challenges involved in maintaining backward compatible in messy, running systems without breaking them. If you take a look at how the HTML5 team resolved the similar problem with rigorously defining a parser that was backwards compatible with the ad-hoc heuristic parsing of various previous flavours of HTML in earlier browsers, you can see the scope of the problem. In particular, you can never have an invalid document in a workable wikitext system: only a document that does something that perhaps does something you didn't expect it to do, otherwise human editing of wikitext will become impossible without programmer-level debugging skills. -- The Anome (talk) 19:04, 17 November 2015 (UTC)

Yes, it has always been known that Parsoid will have a reallly reallllly long tail of edge cases around "broken" wikitext. We have come a really long way towards addressing that. And, yes, we are working with the assumption that there is really no "invalid" wikitext. Instead, we have a bunch of different directions we are exploring for the longer-term. It remains to be seen how these will evolve and which will actually see the light of day in production, but backward compatibility as well as strategies for migration will be an important part of evaluating any of these solutions. SSastry (WMF) (talk) 19:29, 17 November 2015 (UTC)

It's good to know that the VE team are aware that there's no simple obvious clear-cut solution for this: I'm firmly convinced that understanding that is the first stage toward finding a real solution. That's good quality work. -- The Anome (talk) 20:11, 17 November 2015 (UTC)

Hmm, interesting. I've asked if this is something that Check Wikipedia can pick up. Regardless of VE, it might also be bad for 3rd party tools. And it's ugly :). Phab ticket created as well. Though I wouldn't mind if this is tackled in the PHP parser, rather than in Parsoid..—TheDJ (talk • contribs) 09:56, 16 November 2015 (UTC)

Thank you! -- The Anome (talk) 10:20, 16 November 2015 (UTC)

Arlo has fixed this and once this is tested, it will go live. Thanks for the bug report. SSastry (WMF) (talk) 20:56, 16 November 2015 (UTC)

Thank you again. Knowing that bug reports here are listened to and acted on is greatly encouraging. I still remember the earlier fiasco where feedback on the VE was solicited, but turned out to have been simply deleted instead of being read; I spent ages documenting bugs on that one, only to discover it was all in vain. It's nice to see the VE software development effort maturing: the system is definitely becoming production-ready. I wonder if there was a way that this particular bug could have been caught by automated testing? -- The Anome (talk) 18:54, 17 November 2015 (UTC)

Regarding automated testing, it is complicated. Parsoid does do automated roundtrip testing on 160K pages from a bunch of different wikis. But, these only tests Parsoid's ability to cleanly roundtrip what it parses without breaking pages (which is the most important requirement when pages are edited in VE or other clients). We do have a lot of parser tests which we continually update on an ongoing basis (ex: new test added from this bug), but edge cases in parsing come in different forms, and to discover all of them requires mass visual-rendering-diff testing (comparing Parsoid's HTML rendering with PHP parser's HTML rendering). Currently, we have a limited form of visual diff testing in place which we have used to uncover and fix different rendering issues, but detecting real diffs from spurious diffs is a more difficult problem which had prevented its deployment in a large-scale mass testing scenario. But, the good news is that, at the time of this writing, we have made progress on this visual-diff problem. Once this testing framework itself is well-tested (ha! :)), we'll use this to more uncover rendering difference between Parsoid and the PHP parser, as well as for other projects (ex: replacing Tidy with a HTML5 parser). Hope this answers your question. SSastry (WMF) (talk) 19:08, 17 November 2015 (UTC)

Cool. Thanks for all your hard work on this difficult problem. -- The Anome (talk) 20:14, 17 November 2015 (UTC)

Another big problem related to editing a section first in wikitext.

1. Edit a section of an article with wikitext. Say with a link like https://en.wikipedia.org/w/index.php?title=Machadodorp&action=edit&section=3
2. switch to VE
3. make an edit and save

This removes all other sections of the article. See for example section edit to Machadodorp the edit was intended just to link a particular author but instead deleted the rest of the article leaving just the section edited.--Salix alba (talk): 06:37, 19 November 2015 (UTC)

See this recently archived thread: Wikipedia:VisualEditor/Feedback/Archive 2015 3#deleting all but the current section. Status is "patch-for-review" as of 22 November. -- John Broughton (♫♫) 21:32, 19 November 2015 (UTC)

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

It would be helpful to include a way to add an ISBN link.

Presidentman talk · contribs (Talkback) 16:31, 11 November 2015 (UTC)

You can edit pre-existing ones, but it's nowiki-ing new ones (if you just type one out with the WP:ISBN magic word). I'll ask what the plans are. My guess is that it's on the list, but not for soon. Whatamidoing (WMF) (talk) 17:58, 11 November 2015 (UTC)

Added the ticket number. —TheDJ (talk • contribs) 09:59, 16 November 2015 (UTC)

Update: It wasn't supposed to nowiki the new ISBN magic words, and it has been fixed. Whatamidoing (WMF) (talk) 23:44, 22 November 2015 (UTC)

I was doing quite a time consuming edit on National Cycle Route 2. I started in wikitext. Switched to VE. As it was a long edit I saved halfway through. I then started editing again in VE and the popup box asking if I wanted to keep the changes appeared? --Salix alba (talk): 10:21, 21 November 2015 (UTC)

Thanks, that seems to be a new one. Whatamidoing (WMF) (talk) 19:44, 23 November 2015 (UTC)

VE does quite a good job in allowing me to paste in a wikipedia URL like https://en.wikipedia.org/wiki/Southampton and producing an internal link Southampton. It fails if I try something like https://en.wikipedia.org/wiki/Raymond%27s_Hill which has a escaped ' (%27), just inserting an unlinked URL.--Salix alba (talk): 10:30, 21 November 2015 (UTC)

Thanks.

@John Broughton:, would you look at the steps in that bug report, and decide whether that's something we should mention in the user guide? When it works, it's pretty awesome. Whatamidoing (WMF) (talk) 20:23, 23 November 2015 (UTC)

@Whatamidoing (WMF): I'd recommend leaving discussion of this feature out of the user guide. When it works, it's a positive surprise, and when it doesn't, it's what the user might expect; that's not a problem unless a lot of users get frustrated when it doesn't work - and I'd guess that most users encounter this issue so infrequently that they won't care, or remember, when the conversion fails.

More generally, I'd rather not try to explain a mostly-functional feature - I think that way lies more confusion. I'd rather wait until the feature is fully functional, and then add it. That avoids remembering to monitor for a bug fix, and then changing the user manual accordingly. (In this case, since VE does more than might be expected, and any surprise is a positive one, I'm not sure that any explanation at all is needed in the user manual - this feature is an "of course it should do that" matter.) -- John Broughton (♫♫) 18:10, 26 November 2015 (UTC)

I've used the cite conversion tool on an article where the same bare link cite was used more than once. Alas, it just converted that single instance, leaving the others as-is. When bare links are converted to cites, the VE should name the converted reference, check for the presence of any more instances of the same bare link in the article, and convert those to references to that named reference. -- The Anome (talk) 12:15, 26 November 2015 (UTC)

Diff? Whatamidoing (WMF) (talk) 02:47, 27 November 2015 (UTC)

As a related issue to the above, the autoconversion tool should always generate <ref> names for each reference it converts. Ideally, that name could contain some semantically meaningful label made from an author's name or publication name, but even a label like "a26" would be better than nothing. (Of course, whatever name generation process is used, it should contain checks to ensure uniqueness within the article.) Even if this label is not used elsewhere at the time, having it in the article wikitext will make longer-term maintenance of the article easier, even if it's only for editors editing the wikitext directly. -- The Anome (talk) 12:22, 26 November 2015 (UTC)

I'm not sure that we'd be happy with the results if we suggested this idea before phab:T92432 (sensible automatic ref names) or at least phab:T52568 (be able to name refs manually) is fixed. Whatamidoing (WMF) (talk) 02:50, 27 November 2015 (UTC)

I'm guessing that this has been reported many times before, but just in case: this VE edit resulted in a number of unnecessary nowiki tags. (Perhaps ironically, I was using VE to edit a help page about using VE; the edit "broke" the page entirely.) -- John Broughton (♫♫) 20:45, 25 November 2015 (UTC)

Hmm, that's broken indeed. It actually already breaks before saving, the template dialog for that part is not right at all... Ticket filed. —TheDJ (talk • contribs) 12:58, 26 November 2015 (UTC)

This is a Parsoid issue for which I have filed T119802. SSastry (WMF) (talk) 16:38, 30 November 2015 (UTC)

Moved from Talk:VisualEditor

Can I get visual editor for ur.wikipedia.org? — Preceding unsigned comment added by Shansajid (talk • contribs) 11:58, 20 October 2015 (UTC)

Hello, Shansajid. The dev team is working on support for Arabic and Indic languages (among others). Urdu is not working reliably for some users. Therefore, it has not been deployed to most users at ur.wikipedia.org. You can test it yourself by choosing "Visual editing" at https://ur.wikipedia.org/wiki/خاص:ترجیحات#mw-prefsection-betafeatures The team will need help from people who can read and write in Urdu. If you are interested in helping with that process, then please leave a message for mw:User:Trizek (WMF) (or me, if you prefer). Whatamidoing (WMF) (talk) 03:25, 2 December 2015 (UTC)

Please participate in the discussion at Help talk:Citation Style 1/Archive 10#Publisher plus.google.com.

—Trappist the monk (talk) 15:42, 25 November 2015 (UTC)

The problem isn't a procedural one, or one involving a manual of style issue, it's a bug, and it appears to be highly probable that it is being caused by VE. There are more than 2000 instances so far, so this isn't trivial. This page is the proper place to discuss whether VE is indeed causing this problem, and if so, what's an appropriate priority for fixing the problem. -- John Broughton (♫♫) 20:25, 25 November 2015 (UTC)

Example of edit, tagged "Visual edit", adding a |publisher= with a plus.google.com external link and adding an invalid |language=it-IT. Keith D (talk) 02:29, 26 November 2015 (UTC)

This is the information that Citoid was able to gather. It's not perfect however. I'm not sure if there is a concept of allowed types of parameter content in Zotero as strict as there is in Wikipedia. If there is not, perhaps Citoid can transform it when needed. You might wanna file a report in phabricator. —TheDJ (talk • contribs) 12:41, 26 November 2015 (UTC)

@TheDJ: Odd. The Citoid informatiion you provided says this about the publisher:

publisher":"https://plus.google.com/109293916965448553143",

and that URL resolves to this:

https://plus.google.com/+PCMag/videos

Which makes me wonder if editors are somehow citing sources from within a Google+ "shell" (for want of a better word). -- John Broughton (♫♫) 18:02, 26 November 2015 (UTC)

Trappist the monk, do you have an example diff from a relatively experienced editor? I'd like to know what web browser they're using (to follow up on John's idea), and brand-new editors aren't as likely to reply to questions. Whatamidoing (WMF) (talk) 02:45, 27 November 2015 (UTC)

Most of the edits I've looked at seem to be made by inexperienced users. This edit was not such a one. No doubt there are others.

—Trappist the monk (talk) 13:54, 27 November 2015 (UTC)

and another.

—Trappist the monk (talk) 14:05, 27 November 2015 (UTC)

You could try some of the changes to Tim Kasher for 26 November, such as this edit, made by Keegan (talk · contribs) who is a sysop. Keith D (talk) 20:46, 27 November 2015 (UTC)

Okay, I've asked Keegan. -- John Broughton (♫♫) 04:40, 28 November 2015 (UTC)

I was using Chrome, and doing nothing in particular myself that would cause this; it's copy and paste URLs like everything else. Keegan (talk) 08:14, 28 November 2015 (UTC)

Thanks, Keegan. I think that the next step is to find out whether there's anything 'helpful' in the Zotero translator. Whatamidoing (WMF) (talk) 01:57, 29 November 2015 (UTC)

I investigated this at Wikipedia:Editor assistance/Requests#Google Plus as Publisher on links. The first example discussed above is for the source [11] which has this in the html: <link rel="publisher" href="https://plus.google.com/+FootballScoutingIt"/>. VE's "Automatic" option to fill out a reference from a url produces: publisher = https://plus.google.com/+FootballScoutingIt. Html like <link rel="publisher" href="https://plus.google.com/...> is recommended at for example [12]. Such publisher information should probably be ignored when references are generated automatically. PrimeHunter (talk) 02:24, 29 November 2015 (UTC)

Okay, to summarize, the problem is caused because websites have put something like this into their html:

<link rel="publisher" href="https://plus.google.com/+FootballScoutingIt"/>

That was part of Google's authorship markup, functionality that ended in 2014 but apparently lives on in old code.

When such code is on a page, something - either Citoid directly, or Citoid via Zotero [I'm guessing Citoid directly, given the relatively few Zotero translators in place for Wikipedia] is picking up that URL and using it as the publisher parameter.

If problem is Citoid, directly, then the solution is not for Citoid to magically figure out, from the URL, what the true publisher is; rather, Citoid should just stop using the "rel=publisher" URL,, which was designed to create a "knowledge graph ... in the form of the brand’s Google+ page summary" [13]. Instead, Citoid should do its best to figure out the publisher using whatever other algorithms it has.-- John Broughton (♫♫) 21:33, 29 November 2015 (UTC)

It looks like the solution they're exploring is whether the "link rel=" could be followed, and the publisher's name extracted from Google Plus. We'll see whether they make some progress with that. I'm not predicting a rapid resolution. Whatamidoing (WMF) (talk) 17:58, 30 November 2015 (UTC)

We appear to be ignoring the second part of my comment "and adding an invalid |language=it-IT" what is being done about sorting out the invalid language parameters in these citations and avoiding adding language parameter of English. Keith D (talk) 19:18, 30 November 2015 (UTC)

Oh, I'm sorry. That's a known bug: phab:T115326. The devs are discussing how to handle it. (I'm not sure that it-IT actually an invalid language code.) Whatamidoing (WMF) (talk) 18:29, 1 December 2015 (UTC)

For enwiki, at the next update to Module:Citation/CS1, the module will accept IETF language codes as long as the language portion of the code is two characters and the two-character code is found when the module calls mw.language.fetchLanguageName(). It would be nice if there were a similar function that was restricted to listing only the language code registered at the IANA language subtag registry along with a similar function for country codes and better, some way of knowing that the language code / country code pair when used together made some sort of sense: en-IN, es-MX but not pt-IS. Names.php might be adapted but because it serves multiple purposes such adaptation might not be compatible with this use.

—Trappist the monk (talk) 19:57, 1 December 2015 (UTC)

Still would be good to clear up the rubbish rather than just hiding it, AWB currently removes language of English, may be it could be extended to remove the various varieties of English that are being introduced by this. Keith D (talk) 01:35, 2 December 2015 (UTC)

There isn't any real need to delete |language=English. When English is the only language listed, Module:Citation/CS1 ignores it. There are those who would rather that AWB did not remove |language=English as part of general fixes. Certainly those at the WP:MED translation project would prefer that |language=English not be deleted. See this discussion.

—Trappist the monk (talk) 12:40, 2 December 2015 (UTC)

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

URL: https://en.wikipedia.org/w/index.php?title=Andres_Rodriguez_(show_jumper)&veaction=edit&vesection=1&editintro=Template%3ABLP_editintro

1. I would like to delete that [1] note/template I tried to insert but doesn't work. What can I do?

2. Is there any possibility to create an additional box? (i.e. to have two templates?) I tried to create an other one with Andres' Medals but it completely changed the design (all the content went into the template when I saved the page)

Thank you for your reply Regards Stéphane

Stephanefasel (talk) 13:18, 1 December 2015 (UTC)

Hello, Stéphane. I see that you have made a few more changes, so perhaps you have already figured out everything. Usually, if you want to delete something in VisualEditor, you select it (try single-clicking on it) and press the delete/backspace key on your keyboard.

There is no limit on the number of boxes. I think that the problem you encountered was trying to use the wrong template. ((MedalTableTop)) is incompatible with ((MedalBottom)). It looks like you figured out which ones you needed. Congratulations on that achievement – I know it's very confusing. Happy editing, Whatamidoing (WMF) (talk) 18:33, 2 December 2015 (UTC)

Hi, in this edit, VE damaged a well formed titled by putting it at the end of the previous line (keeping the ==). --NicoV ^{(Talk on frwiki)} 20:14, 3 December 2015 (UTC)

This is T105745 which will get resolved as part of T86271 for which there is a patch awaiting final review in gerrit. SSastry (WMF) (talk) 16:48, 5 December 2015 (UTC)

Following on from discussion above about VE auto filling in of references there is a problem with this always completing dates in ISO format rather than honouring the date format of the article. Thus you end up with much more inconsistency in articles and have to keep following round edits to put the dates in the right format for the article such as day first format. The added reference should have its dates in the major format of the article, ISO being used if there is a mixture that you cannot determine which format to put it in. The presence of ((use dmy dates)) or ((use mdy dates)) templates can show which to use. Keith D (talk) 01:45, 2 December 2015 (UTC)

Thanks for this note, Keith. In the past, the devs have usually refused to making VisualEditor do something to comply with a template that only exists on 5% of Wikipedias (which is how un-widespread ((Use dmy dates)) is). It might be more efficient to have the CS1 modules comply with those templates. That would have the happy effect of transforming the many mismatched dates that are added in the wikitext editor, too (within citation templates, at least). Whatamidoing (WMF) (talk) 18:07, 2 December 2015 (UTC)

This would not be that useful for dates which are entered that look like ISO format but are not actually such as yyyy-dd-mm, dd-mm-yyyy etc. Really need to clean the wiki text to make them understandable to editors using either editor so that the text and the display is the same. Keith D (talk) 18:54, 2 December 2015 (UTC)

I suspect that Lua can figure out the difference between four-two-two and two-two-four and process both of them correctly. That leaves you only with the rare instance of an editor manually typing mm-dd-yyyy as a date (is 01-02-2010 January 2nd or February 1st?), but you will have that problem no matter what you do. Whatamidoing (WMF) (talk) 02:27, 8 December 2015 (UTC)

Not sure if this is the right place to bring this up, but I can't figure out how to assign names to references using VE. If I choose to reuse an existing reference, VE will name the reference with names like :0 and :1. I can't figure out how to change this short of manually editing the reference name (which is fine for me, but VE isn't for people like me - it's for new users). Am I correct - is it actually impossible to edit reference names within VE? Guettarda/Ian (Wiki Ed) (talk) 18:18, 2 December 2015 (UTC)

You are correct. It is no longer possible to add or change reference names manually in VisualEditor. VisualEditor's automatic names are unfriendly to humans. Both of these things are on the list for improvements.

In practice, having human-friendly ref names is not usually important to people who are only using VisualEditor. They have no need to know what the ref tag's name is, because re-using the ref doesn't require knowing the name (unlike re-using the ref in the wikitext editor). Whatamidoing (WMF) (talk) 18:36, 2 December 2015 (UTC)

True, but they interact with the rest of the editing community. And new editors make enough mistakes that annoy established editors[14] - I'm trying to figure out how to help student editors avoid these kinds of problems. (That said, I'm really happy with the current incarnation of VE. Recent improvements have finally shifted me from skeptic to supporter.) Ian (Wiki Ed) (talk) 18:46, 2 December 2015 (UTC)

There are several tasks in Phabricator to address this. I want VisualEditor to provide sensible names by default (using text extracted from the |author= and |date= fields in the citation templates) and to allow editors to re-name them manually. However, I'm not realistically expecting progress on either of these points during the next few months. Whatamidoing (WMF) (talk) 02:31, 8 December 2015 (UTC)

Many articles expose bare urls in their refs. I'd love for ve to offer a way to fix this. If a ref is formatted as <ref>http://.... I'd love for VE to put the url in one field and offer a second field where I could put the title. This is particularly important for pdfs and for the NYT that don't respond well to VE's cite builder. Thanks! Lfstevens (talk) 07:11, 6 December 2015 (UTC)

@Lfstevens: I just added a bare URL to my sandbox article, to test this, using the wikitext editor. In VE, when I click on that reference, a dialog opens that includes a "Convert" button; when I click that, VE (Citoid, to be exact) tries to create a full citation.

If the citation that's built isn't very good - actually, if it's not perfect - then I still click "Insert", because the dialog then offers an "Edit" button. When I click on that, I can fix the citation - add a title, fix the source date (it's always in YYYY-MM-DD format, which I detest), etc.

In short, it looks to me like (1) VE does offer a quick way to try to fix bare URLs, and (2) to the extent that the citation that is built isn't very good, there is an easy way to improve it. So I'm probably missing the point of your posting - could you explain further? -- John Broughton (♫♫) 22:21, 6 December 2015 (UTC)

I tried these variants:

<ref>http://www.graphene.manchester.ac.uk/</ref>

Showed a convert button. Clicked it and got an error about the title.

<ref>[http://www.graphene.manchester.ac.uk/]</ref>

Showed an edit button. Clicked it and got [1]. Clicked that and got a link dialog. Clicked Edit and got an editable link with an Add Label button. Clicked that and got an edit box that included the url. Added some text. Clicked Done. Back to the Link dialog. No Done button there.

What I'd prefer is a Convert button.

<ref>[http://www.graphene.manchester.ac.uk/ aaa]</ref>

Got a Convert button. Clicked Convert. Got the title error.

<ref>[http://www.graphene.manchester.ac.uk/</ref>

Got an editable url. Added a bracket. Got this:

<ref>[http://www.graphene.manchester.ac.uk/ asdf]</ref>

<ref>http://www.graphene.manchester.ac.uk/]</ref>

Got an editable url, selected, with the Link dialog covering up the url. Edited the url without clicking the edit button. Got this:

<ref>[http://www.graphene.manchester.ac.uk/ [http://www.graphene.manchester.ac.uk/]]</ref>

<ref>[http://www.graphene.manchester.ac.uk/ aaa</ref>

Got an editable url. Added a bracket. Got this:

<ref>[http://www.graphene.manchester.ac.uk/ aaa]</ref>

<ref>http://www.graphene.manchester.ac.uk/ aaa]</ref>

Got an editable url, selected, with the Link dialog covering up the url. Edited the url without clicking the edit button. Got this:

<ref>[http://www.graphene.manchester.ac.uk/ [http://www.graphene.manchester.ac.uk/] aaa]</ref>

Finally, I'd change the Convert process so that after conversion it takes you to the fields dialog without the intermediate Insert and Edit steps.

Cheers! Lfstevens (talk) 01:59, 7 December 2015 (UTC)

I tried your first example. Here's what's in the "Add a citation" dialog box (website template), after clicking "Convert"

"Graphene | The University of Manchester". www.graphene.manchester.ac.uk. Retrieved 2015-12-07. C0 control character in |title= at position 10

Note: this doesn't prevent the next step - Inserting the citation into the body of the text - from happening.

I click "Insert", then "Edit", and then things such as the title can be fixed. That's a bit lengthy, but seems straightforward.

You're suggesting that "Convert" essentially replace three clicks - Convert, Insert, and Edit. When an editor intends, at least most of the time, to improve Citoid-created references, then yes, one click is quicker than three. On the other hand, how many editors are going to just click Insert and be done with it?

You can still have an Insert (or Apply) button on the cite editing dialog. That way you don't add clicks who are happy with what Convert produces. Better to use Done/Cancel for consistency.

It is possible to provide editors with a choice of either fully accepting Citoid's reference, or fixing the reference, in one integrated process, which would eliminate two clicks: when the "Add a citation" dialog (with its "Insert" button) appears, also display, on the right, the Cite web dialog. (Essentially, the "Add a citation" dialog calls the Cite XXX template, and accepts any changes.)

This suggested approach means that editors have a one-click choice - accept the parameters supplied by Citoid, and be done, or, alternatively, update them, and use the revised parameters. -- John Broughton (♫♫) 20:58, 7 December 2015 (UTC)

Exactly. I assume the lack of commentary on the other use cases means that you see what needs to be done. Cool! Lfstevens (talk) 05:39, 8 December 2015 (UTC)

Currently, something like ((subst:foobar)) seems not to be substituted in a reference. Is it possible to insert ((subst:#tag:ref)) instead of <ref></ref> as a reference? I cannot think of drawbacks in this change but I want to hear from experts about the problem. ktns (talk) 18:24, 5 December 2015 (UTC)

Subst doesn't work inside of ref tags because of a bug filed back in 2005. See phab:T4700.

You can add (through the complex transclusion editor at Insert > Template) something like ((subst:#tag:ref|((subst:NUMBEROFACTIVEUSERS)))), which results in the wikitext <ref>126,428</ref> being added at the moment. But why would you want to do this? Whatamidoing (WMF) (talk) 02:43, 8 December 2015 (UTC)

I want this feature to set current date like ((subst:CURRENTMONTH)) ((subst:CURRENTYEAR)) for parameters such as date parameter of ((dead link)). With this feature, I think it is convinient to be able to set current date as default value for such parameters. ktns (talk) 15:28, 8 December 2015 (UTC)

Ah, you want this, except for it to work. ;-) At the moment, I think the only option is to use the complex tranclusion editor. It's definitely a kuldge, but it will let you insert wikitext directly. You can see the steps at mw:VisualEditor/Complex transclusion. I think you'll be able to sort it out from there. Whatamidoing (WMF) (talk) 19:28, 9 December 2015 (UTC)

trespassers william (talk) 17:51, 9 December 2015 (UTC)

Tracked in Phabricator
Task T52896

It's been known for some time that VE doesn't properly handle footnotes within a template (in this case, an infobox). Since infoboxes are widespread, particularly for the more important articles, and editors are encouraged to add citations to all content, infoboxes included, the problem is only going to get worse.

Currently #5 at Wikipedia:VisualEditor/Known problems. -- John Broughton (♫♫) 00:34, 10 December 2015 (UTC)

I've posted a complaint at Phabricator that this issue should be given considerably higher priority. Currently it's unassigned, which means it's not being worked at all. -- John Broughton (♫♫) 17:30, 11 December 2015 (UTC)

Being able to control sortability would be extremely useful by adding class="sortable" to the style to bring it in line with the Wiki Markup toolbar. T.Shafee(Evo﹠Evo)^talk 12:49, 4 December 2015 (UTC)

I am surprised to report that I couldn't find an open task for this, so I've created a new one. It's at phab:T121267. There is a very good chance that this will be addressed by April at the latest. Whatamidoing (WMF) (talk) 20:05, 11 December 2015 (UTC)

Dominikmatus (talk) 22:15, 14 December 2015 (UTC)

Thanks, Dominikmatus. I've reported this problem. I appreciate you telling me about it. Whatamidoing (WMF) (talk) 18:56, 15 December 2015 (UTC)

The VisualEditor recently expanded the mathematics tool, and I'm looking for more feedback on the overall design, whether it seems to be working for you (browser/OS if it's not), and whether anything significant is missing. Click here to play in my sandbox if you want to start on a page that contains a math formula. Double-click on existing formulae to open them, or go to Insert > More > Formula to add new ones, and let me know what you think. Whatamidoing (WMF) (talk) 21:16, 14 December 2015 (UTC)

Vector theme, Firefox 42.0, Mac OS X 10.8.5. If I edit a formula, press Cancel, and then edit the same formula again, the second edit starts from where my first edit left off, even though I did not save that work. I expected to see a fresh, unedited copy of the saved markup on my second edit. To put it another way: If I wanted to discard incomplete work on an edit and start anew, how could I do that? Thanks. Mgnbar (talk) 21:29, 14 December 2015 (UTC)

Vector, OS X Yosemite 10.10.5, Firefox 42.0. The tool is very nice! But there are some changes I would make.

1. Some of the "standard" numerical functions are obscure, and some standard functions are left out. Here is the list of functions I would use.
   • Exponentials and logarithms: exp, log, lg, ln, log₁₀, arg, Li_s (the polylogarithm)
   • Trigonometric functions: sin, cos, tan, sec, csc, cot, arcsin, arccos, arctan, arcsec, arccsc, arccot
   • Hyperbolic trigonometric functions: sinh, cosh, tanh, sech, csch, coth, arsinh, arcosh, artanh, arsech, arcsch, artanh
   • Probability and statistics: erf, erfc, logit
   • Complex functions: Re, Im
2. And if you want to add more functions, here are some other useful operators:
   • Trigonometric, exponential, and logarithmic integral functions: Si, si, Ci, Cin, Shi, Chi, Ei, Ein, Li, li
   • Airy and Scorer functions: Ai, Bi, Gi, Hi
   • Signal processing function: sinc
   • Jacobi elliptic functions: sn, cn, dn, cd, sd, nd, dc, nc, sc, ns, ds, cs
3. The "bounds" section is misnamed, and some of the functions there are misplaced. I would rename it "Limits and extrema" and include the following functions:
   • max, min, sup, inf, lim, lim sup, lim inf
4. The "projections" section is misnamed. I think the operators there are better placed under other headings.
5. I have several suggestions for "derivatives and differentials".
   1. The integrals should be moved here, and the section renamed "Calculus".
   2. We might benefit from a button for ${\displaystyle {\frac {\partial ^{2}f}{\partial x\partial y))}$. (It's similar to ${\displaystyle {\frac {\partial ^{2)){\partial x_{1}\partial x_{2))}y}$, of course, but I don't see anything wrong with adding more buttons.) Also maybe ${\displaystyle {\frac {\partial ^{3}f}{\partial x\partial y\partial z))}$.
   3. There are buttons for several operators that should be discouraged, namely, those with an upright d (as in dt, dy/dx). The consensus of WikiProject Mathematics is that this notation represents a misunderstanding of differentiation, and that derivatives and differentials should always be written with an italic d (as in dt, dy/dx). In addition, having both notations may suggest to editors that dt and dt are different concepts, when in fact they're the same. (That said, the MOS allows both notations, since there are respectable publications that use an upright d.)
   4. There is a button for f^\prime and a button for f'. These are synonyms, so there should be only one button.
   5. The button for ${\displaystyle f^{(3)))$ actually inserts ${\displaystyle f^{3))$.
   6. All the fraction-like operators are written using \over instead of \frac. I'll admit that the differences between the two are too esoteric for me to understand, but most people seem to use \frac.
6. Under "modular arithmetic", the a mod b button inserts a\,\bmod\,b when it should insert a\bmod b. Wikipedia currently renders the latter with too little space, but the correct solution is to fix the rendering of \bmod instead of inserting hard formatting commands everywhere.
7. The "operators" section should have ${\displaystyle \wedge }$.
8. Under "logic", I'm confused by the four buttons for ${\displaystyle {\bar {q))}$, ${\displaystyle {\bar {abc))}$, ${\displaystyle {\overline {q))}$, and ${\displaystyle {\overline {abc))}$. Firstly, these operators are not logical operators, so they ought to go elsewhere, probably under accents and diacritics (in fact ${\displaystyle {\bar {a))}$ is already there). Secondly, I don't think four buttons are needed. It would suffice to have ${\displaystyle {\bar {a))}$ and ${\displaystyle {\overline {abc))}$.
9. "Arrows" needs an \xrightarrow button, say ${\displaystyle {\xrightarrow[{b}]{a))}$, and an \xleftarrow button, ${\displaystyle {\xleftarrow[{b}]{a))}$. (These appear together under Large Layouts, but usually you just want one arrow.)
10. Under "typefaces", the first button produces ${\displaystyle mathit{1))$, not ${\displaystyle {\mathit {1))}$.
11. Also under "typefaces", the button labeled "x" was mysterious to me. Since it produces \text, I suggest that it say "text".
12. The parentheses section needs ${\displaystyle \lfloor x\rceil }$ (this is a common notation for rounding).
13. Fractions should not be in the matrices section. They might deserve their own section if they don't fit anywhere else.
14. In fact the matrices section should be renamed "Matrices and linear algebra", and it should acquire some operators that currently appear elsewhere: im, ker, coker, det, dim.
15. Here are several comments on "Subscripts, superscripts, and integrals".
    1. It seems superfluous to have ${\displaystyle 10^{30))$ and ${\displaystyle a^{2+2))$. I think an ${\displaystyle a^{10))$ button might work better.
    2. The ${\displaystyle {}_{1}^{2}\!\Omega _{3}^{4))$ button should be a ${\displaystyle {}_{1}^{2}\Omega _{3}^{4))$ button. There is no need for a negative space right there.
    3. The difference between ${\displaystyle {\overset {\alpha }{\omega ))}$ and ${\displaystyle {\underset {\alpha }{\omega ))}$ isn't clear from the buttons. I think the only way to fix this is to align the baselines of the buttons. (The same problem occurs with \ldots and \cdots in the "Special" section.)
    4. Four symbols for ${\displaystyle x'}$, ${\displaystyle y''}$, ${\displaystyle f'}$, and ${\displaystyle f''}$ is superfluous, especially when prime marks already appeared in the calculus section.
    5. I think the \overleftarrow, \overrightarrow, \widehat, \overline, and \underline commands fit better among the diacritics.
    6. There is never any use for ${\displaystyle \textstyle \int \limits _{-N}^{N}x}$. The combination of \textstyle and \limits is always a bad idea. Even using \limits on an integral, as in ${\displaystyle \int \limits _{-N}^{N}x}$, is usually not a good idea, though it has a few uses.
    7. The integrals should come with properly formatted differentials, as in ${\displaystyle \int _{a}^{b}f(x)\,dx}$, ${\displaystyle \int \limits _{a}^{b}f(x)\,dx}$, ${\displaystyle \textstyle \int _{a}^{b}f(x)\,dx}$, ${\displaystyle \iint \limits _{D}f(x,y)\,dx\,dy}$, and so on.
    8. There should be buttons for ${\displaystyle \iint _{D}f(x,y)\,dx\,dy}$ and ${\displaystyle \textstyle \iint _{D}f(x,y)\,dx\,dy}$.
    9. The union and intersection operators need \textstyle versions, ${\displaystyle \textstyle \bigcup _{i=1}^{n))$ and ${\displaystyle \textstyle \bigcap _{i=1}^{n))$.
16. The large layouts section should have the generalized hypergeometric function ${\displaystyle {}_{p}F_{q}\left({a_{1},\ldots ,a_{p} \atop b_{1},\ldots ,b_{q));z\right)}$.
17. There should be an "Algebra" section with the operators deg, ker, im, coker, coim, Hom, lim, colim, inj lim, proj lim, ${\displaystyle \varinjlim }$, ${\displaystyle \varprojlim }$, holim, hocolim.

I think that's all for now. Ozob (talk) 04:04, 15 December 2015 (UTC)

Here are some additional operators that should be added:

1. Under "Calculus": div, grad, curl
2. Under "Algebra": ${\displaystyle \operatorname {GL} }$, ${\displaystyle \operatorname {SL} }$, ${\displaystyle \operatorname {O} }$, ${\displaystyle \operatorname {SO} }$, ${\displaystyle \operatorname {U} }$, ${\displaystyle \operatorname {SU} }$, ${\displaystyle \operatorname {Sp} }$, ${\displaystyle {\mathfrak {gl))}$, ${\displaystyle {\mathfrak {sl))}$, ${\displaystyle {\mathfrak {o))}$, ${\displaystyle {\mathfrak {so))}$, ${\displaystyle {\mathfrak {u))}$, ${\displaystyle {\mathfrak {su))}$, ${\displaystyle {\mathfrak {sp))}$.

Ozob (talk) 20:29, 15 December 2015 (UTC)

More of a general comment than a bug report, but it seems like cross-wiki uploads via VE have a significantly higher rate of copyvios compared to the "old" upload methods. Especially logos and similar content seem to be problematic. In the last 2 days I noticed 4 of such cases (obviously that's nowhere near a sufficient sample size), and skimming briefly through Commons recent "cross-wiki" uploads the failure rate could be as high as 20-30 percent. A few questions: 1) is anyone still monitoring those uploads to analyze the feature's rate of wrong uploads? 2) Is anything planned to improve this feature? Frankly, two sentences of vague information and a trivial checkbox isn't exactly "high-tech security". Especially new editors are left alone with almost no meaningful advice. Of course a simple browser-based application cannot explain everything about copyright in 5 minutes - but a bit more specific advice could be useful. Also, the information text should be displayed more clearly as "warning", not merely as skippable "information" (red is a great color for instance, or a warning sign might help a bit). GermanJoe (talk) 22:41, 3 December 2015 (UTC)

This is being discussed at phab:T120867. We are currently missing information about whether the main variable is the inexperience of the uploaders (this is the first-ever upload for nearly all of them) or the tool being used. Whatamidoing (WMF) (talk) 19:55, 11 December 2015 (UTC)

In case anyone's interested, there's been some research done on this. It appears that new(!) contributors who use the cross-wiki upload system have the same problem (or even fewer) than new contributors who use the UploadWizard at Commons. It looks worse at first glance, because the in-editor tools are used almost exclusively by new contributors. Once you remove people who use UploadWizard frequently, it turns out that the tools are irrelevant (or that cross-wiki uploads are better than newbies who went straight to Commons). Whatamidoing (WMF) (talk) 20:06, 16 December 2015 (UTC)

You'll have to consider the absolute number of uploads as well, even if the relative number of errors for specific usergroups might not change that much (but good to know that detail). Of course it's a positive development, when such a tool leads to more usable images. But on the other hand, someone has to clean up the increasing number of erroneous uploads (in absolute numbers). If the cross-wiki feature leads to an increased participation of new users, it must be "better" than the old venues in advice and security for that inexperienced usergroup. Otherwise Commons, with a stagnating number of admins and an already existing huge backlog, will be facing an increasing number of problematic files. GermanJoe (talk) 21:12, 16 December 2015 (UTC)

At the moment, about 5% of all uploads to Commons are from newbies using the cross-wiki tools, and about 5% of all uploads to Commons are from newbies using the UploadWizard. Almost 90% of uploads to Commons are from previous users. Based on one list I saw, we're talking about a few hundred images per day, the majority of which are appropriate. Whatamidoing (WMF) (talk) 18:30, 17 December 2015 (UTC)

See history:

• Successive small tags, here also
• Span tags, including one with internal VE attributes
• Multiple blockquotes: any reason ?

Please fix. --NicoV ^{(Talk on frwiki)} 15:19, 13 December 2015 (UTC)

• I think I reproduced this once while playing on that page, but i couldn't do it a second time. Maybe there is a race condition in when the style of pasted blocks is matched to the 'local' style or something strange like that ?
• I opened phab:T121588.
• I can't find a way to do this other then cell by cell, which is rather laborious honestly.. Perhaps the user just wanted to style the text and he thought this was simply 'prettier' ?

—TheDJ (talk • contribs) 23:37, 15 December 2015 (UTC)

It's not hard to reproduce the "small" problem. See this diff. The steps are this:

1. Realize that you can't set <small> in VisualEditor, and decide that you want to use it anyway.
2. Copy a word that's already formatted with <small>.
3. Go to the line where you want this, and paste your word after a normal, unformatted space.
4. Select and change your word to whatever you want.

If you pasted it near pre-existing small text (e.g., there is already a source listed and marked as small text, and you are pasting in a second source, perhaps on multiple lines throughout the document), then you'll get <small>original</small> <small>new</small> – "original" in small text, a normal size space, and "new" in small text.

Since some people use <small> and <big> to visually adjust the size of spaces, I'm not certain that this is something that Parsoid should disallow. Whatamidoing (WMF) (talk) 18:40, 16 December 2015 (UTC)

You didn't look at all the small tags, for the one before the last one, there's not even a space between, the opening small tag is just after the previous closing small tag. --NicoV ^{(Talk on frwiki)} 19:28, 16 December 2015 (UTC)

The "Bruce Boxleitner" line? Whatamidoing (WMF) (talk) 19:53, 17 December 2015 (UTC)

Whatamidoing (WMF) Yes, this line, where VE added a </small> just before a <small> without anything in between... But even the ones with a whitespace character in between should be handled properly without creating a complete mess in the wikitext. --NicoV ^{(Talk on frwiki)} 03:40, 18 December 2015 (UTC)

User agent: Mozilla/5.0 (X11; CrOS armv7l 7520.63.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

URL: https://en.wikipedia.org/w/index.php?title=Lua_(programming_language)&section=7&veaction=edit

75.110.221.86 (talk) 01:11, 20 December 2015 (UTC)

VE is adding infoboxes without newlines. This make it very hard for people not using VE to manually edit the infoboxes. Examples are [15] and [16]. Bgwhite (talk) 22:42, 15 December 2015 (UTC)

The TemplateData for the templates needs to be updated, to specify that newlines are wanted ("block" formatting rather than "inline"). Whatamidoing (WMF) (talk) 18:42, 16 December 2015 (UTC)

Is this parameter documented somewhere and, more generally, is there an actual list of all supported parameters and their settings? Currently the tutorial seems to lack a few of the newer settings, and I wasn't able to find the parameter in a VE update message (but maybe I overlooked it). GermanJoe (talk) 20:01, 16 December 2015 (UTC)

GermanJoe, I haven't written JSON by hand in months and months. In the GUI, it's the second item (labeled "Template preferred format"). Click the "block" button. It's described at mw:Help:TemplateData#Description and parameters. The official specification is on Github and is theoretically always complete. (Check your talk page for a related note.) Whatamidoing (WMF) (talk) 19:50, 17 December 2015 (UTC)

@Whatamidoing (WMF): Thanks for the tip, worked for me. I rarely use the JSON editor though - it's not compatible with activated WikEd (and I always forget to turn WikEd off first - but that's my own problem). GermanJoe (talk) 06:03, 19 December 2015 (UTC)

We are yet to add support in Parsoid to read TemplateData and apply it to serialization of templates. This is tracked in T111674. But, should be ready by end of January. We are entering the holidays and 3-week deployment freeze period. SSastry (WMF) (talk) 23:31, 16 December 2015 (UTC)

Sigh. Whatamidoing (WMF), I'm getting tired of you blowing me off and saying it is the editor's fault, not VE's. You are NOT supporting "the editor's needs and wants", which according to your user page is your job description. As you didn't look at my examples.... I gave one to ((Infobox person)), which the TemplateData on the page says IS "block". The other example has no TemplateData. Your answer was worthless. You and the crickets at the phab tickets we have filed are single handily making me consider giving up on Wikipedia, something that death threats, doxxing and general Wikipedia "madness" hasn't done. I'm really, really tired of the extra hours spent fixing VE's errors. Errors you do not acknowledge and error tickets that are not fixed. The lack of newlines is an error on Parsoid's part, not editors who write TemplateData. Seeing <nowiki><ref> or <ref><nowiki> is an error. Having editors copy <li> instead of using * is an error and impacts accessibility... stop blaming editors. VE should fix it or not cause it.

SSastry (WMF) Thank you for your answer. Of the top 10 most used infobox templates, Infobox Person is the only template to use block. In the ticket you gave, Jdforrester-WMF said, "Inline is the current behaviour and only rarely has issues. This would not be the case if we reversed the default." Does anything need to be done with block vs inline as Whatamidoing suggested? What else needs to be done and are the template editors aware? Bgwhite (talk) 08:46, 17 December 2015 (UTC)

Small point. I'm the one who added it to Infobox person, AFTER reading about this problem and remembering that something was being worked on to document this with TemplateData. But as ssastry states, this is apparently not yet actually being used just yet. The paramater is documented here and has been for a while, and the JS editor for TemplateData also shows this option for editing. —TheDJ (talk • contribs) 09:13, 17 December 2015 (UTC)

Thank you TheDJ. It appears nobody on enwiki was told about this issue. It's still worrisome that almost all Templates are inline and the editor will default to inline, thus VE will still cause problems. Bgwhite (talk) 09:26, 17 December 2015 (UTC)

People on the English Wikipedia have been told about the ability to "use TemplateData to indicate how you want a template to be displayed in wikitext". This ability was announced as being functional "soon" in Tech/News a month ago.

However, we seem to have very few editors here who are interested in editing TemplateData for templates that they aren't personally using, and they may have other priorities. Making this change isn't difficult: you edit the /doc page, click the "Manage TemplateData" button to open the GUI, click the "Block" button, and save the page. Whatamidoing (WMF) (talk) 19:50, 17 December 2015 (UTC)

Bgwhite, there was a premature announcement in tech news that this feature was ready (I cannot find the phab ticket offhand right now, but I can dig it up if required). What was ready was the solution to support adding this information to TemplateData, but not the work on Parsoid's end to use it. On the Parsoid end, we had another blocker which we fixed and deployed about 2 weeks back. The final piece of this on the Parsoid end needs to be started, but between holidays and a lot of other ongoing work, we haven't been able to pick it up. Anyway, since I knew there had been some confusion about the long chain of dependent tasks, I came in to clarify. But yes, even after Parsoid adds support for reading TemplateData and uses it, template authors / editors would have to add this information to TemplateData which is what User:Whatamidoing (WMF) was alluding to. Does this answer your question? SSastry (WMF) (talk) 16:59, 17 December 2015 (UTC)

You're probably thinking about phab:T64147. Whatamidoing (WMF) (talk) 19:50, 17 December 2015 (UTC)

SSastry (WMF) Yes, that answers my questions. It also means the majority of templates added will be screwed up for the ~97% of the editors who don't use VE. The default setting will be set to screwed up. Every TemplateData has to be changed, which won't happen. Sigh.... Bgwhite (talk) 22:19, 17 December 2015 (UTC)

Thanks User:Whatamidoing (WMF) - that was the task I was thinking of. Bgwhite, how did you infer the "majority of templates" part? If most templates are written using the inline format, and that is the default, then this would affect a non-majority of templates, I think. Anyway, that apart, unfortunately, there is no magical way for Parsoid to know what templates need to be serialized in what form. So, while you and I wish there were an oracle or system for conveying this information, there isn't. Given this situation, TemplateData is the go-to solution that has emerged for conveying template-specific information (from editors and template authors) to editing tools (and Parsoid) that lets these tools do things that editors can be happy about. If there is an interim solution as a fallback for when TemplateData is not available, I am open to incorporating that information. SSastry (WMF) (talk) 23:52, 17 December 2015 (UTC)

Well, lots of articles have one infobox, so it's likely that most articles would have one formatting problem. But the vast majority of templates are indeed handled inline rather than block. Here's a list of the 25 most popular templates (from a list that was made earlier this year): R from title without diacritics, R from other capitalisation, Start date, Main, Birth date and age, Citation, Flagathlete, Use dmy dates, Citation needed, Dts, Sfn, Sort, Sortname, Fb r, Persondata, Goal, Flag, Coord, Cite journal, Cite book, Convert, Cite news, Reflist, Flagicon, Cite web. Here's a list of the 25 most popular templates that didn't have TemplateData defined: IranCensus2006, EngvarB, No footnotes, Empty section, R from US postal abbreviation, Redir from US postal ab, R from alternative language, R to section, Use Australian English, POL, Surname, Tracklist, Short pages monitor, Str ≤ len, YouTube, R from alternative punctuation, National Register of Historic Places, Official, Geobox2 end, En icon, Geographic location, Gnis, Infobox Officeholder, MetroLyrics song, Lang-ar. How many in that list do you normally expect to see typed with one parameter per line? I spotted two among these 50 that are usually given block formatting, and one of them (((PERSONDATA))) has since been deprecated and is being removed. It would take a lot of work to be certain, but I think that the guesstimate of 97% is not too far from reality: probably 97% of templates that need inline formatting (e.g., ((fact|date=December 2015)). Whatamidoing (WMF) (talk) 18:52, 21 December 2015 (UTC)

Red Fiona (talk) 21:08, 18 December 2015 (UTC)

Update - it's working fine again now. Most confusing. Red Fiona (talk) 23:46, 19 December 2015 (UTC)

The citoid service only works if a whole series of computers systems is working correctly (several on the WMF side, plus the webpage for the reliable source that you want to cite and another webpage that tells citoid where the title, author, etc. is located on the reliable source's webpage). My guess is that one of them was offline when you tried to set up this citation. I'm glad it's working again. Whatamidoing (WMF) (talk) 18:56, 21 December 2015 (UTC)

Looks like a minor bug: clicking on any template once (i.e. in Hockenheim, Windows XP, FF 42.0, vector skin) displays the correct puzzle symbol, but next to it the text "Item" is displayed instead of "Template" (it should also immediately display the name of the clicked template, afaik). That preview window (or however developers call that small initial window :) ) also lacks an "Edit" button. Other preview windows for other types of insertable elements seem to be OK, although I didn't check every element type (Media, Reference, Reference list and Link were OK at least). GermanJoe (talk) 05:52, 19 December 2015 (UTC)

I'm also seeing this bug in Firefox 43.0 and Chromium 47.0.2526.73 on Xubuntu 14.04 using monobook. Templates can be interacted with in the usual way by double clicking or by pressing enter after selecting with a single click. Thryduulf (talk) 23:04, 20 December 2015 (UTC)

And in Safari on my Mac, which means that it's everyone, everywhere. I've pinged the only dev I could find online to have a look ASAP. Whatamidoing (WMF) (talk) 19:07, 21 December 2015 (UTC)

I am currently seeing any template present in the VE as "item" without the ability to edit it. Using Chromium on Ubuntu Linux 15. --User:Ceyockey (talk to me) 04:00, 21 December 2015 (UTC)

@Ceyockey: - pressing Enter after that small window is displayed, or double-clicking directly on the template itself, should still work to open the template window (just tested). See the previous report further up. GermanJoe (talk) 06:15, 21 December 2015 (UTC)

Thanks for posting the workaround, GermanJoe. I've filed the bug report. Whatamidoing (WMF) (talk) 19:08, 21 December 2015 (UTC)

Ah, and it appears that Rummana found this well before any of us mere mortals, and a patch is already on the way... assuming they can get permission to deploy it. (Most deployments are stopped for the holidays, because it anything goes wrong, there aren't very many people around to clean up the mess.) Whatamidoing (WMF) (talk) 19:12, 21 December 2015 (UTC)

This is regarding the dit i made using VisualEditor: https://en.wikipedia.org/w/index.php?title=ISO_3166-2%3AGB&type=revision&diff=696177228&oldid=695880839

I just added a new row using the option "Insert above", but looks like when i actually look at the Wiki code, it is not produced as expected. --Siddhant (talk) 12:20, 21 December 2015 (UTC)

Thank you for this note, Siddhant. That is very strange wikitext. I'm surprised that it displays correctly. I've asked User:SSastry (WMF) to look at it; he's really the world expert on this kind of problem. Whatamidoing (WMF) (talk) 19:23, 21 December 2015 (UTC)

There is nothing wrong with the wikitext itself. You can nest tables in HTML and that wikitext is producing well-nested tables. So, I will leave it to VE engineers to investigate why VE generated a nested table for that edit. SSastry (WMF) (talk) 19:31, 21 December 2015 (UTC)

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

When we click on "Review your changes", we're presented with a green highlighted button "Save page" at the top right even if we didn't write an edit summary. The "Return to save form" button should at least be put at the left of the "Save page" button", instead of being hidden at the very bottom of the page.

The RedBurn (ϕ) 11:31, 21 December 2015 (UTC)

Thanks for this comment. I'll pass it along to the product manager. Whatamidoing (WMF) (talk) 19:13, 21 December 2015 (UTC)

Thanks! The RedBurn (ϕ) 21:53, 22 December 2015 (UTC)

As a VE user, what I am supposed to do with a disambiguation page like Shandon? I went there to add a new entry Shandon, Rockhampton which needed an Australia heading added. When I looked at the other country headings, e.g. Republic of Ireland, they appeared as Paragraph format but without any bold formatting (as far as the VE was admitting), yet were visibly bold. That is they were different to the word "Shandon" in the first line which was Paragraph/Bold (said VE). So I created the heading Australia by using Paragraph/bold so it looked consistent with the other headings. I experimented with using Subheading1 but, although bold, the font is larger than the other headings. But Subheading2 does look about right. I think a VE user is likely to be somewhat confused by this.

But of course as a long-time source editor user, I guessed the other headings were done using ";" (which I confirmed after saving my VE edit with a quick peek in the source editor).

So, I think disambiguation pages are soon going to become enormous messes as more VE users edit them using manually bolding or some type of Subheading format. And fixing these will be seen as "creating more work for the community". (I guess the day will come when VE users are seen as part of the community and not some external agents of evil, but that day doesn't seem to have dawned).

I know someone will point out that the use of ";" in this way is evil, but can we skip that conversations in favour of recognising it's a reality. There's lots of them and they are widely used on disambiguation pages in particular, where people seem to be resistant to the visually heavyweight presentation of using ==Whatever== to create sections within lists.

Could we present ;Whatever to the VE user as a new para format "List header/Term" in the drop-down with Paragraph/etc? So that way they can see them and create them consistent with the rest of the disambiguation page (or wherever they are encountering them). I don't know if this is feasible but maybe only offer this format option if it's actually in use in the article (that is, don't offer it if the article isn't using it to discourage the proliferation of even more evil semicolons). Kerry (talk) 20:56, 22 December 2015 (UTC)

You are correct on all counts. Eventually, the visual editor will support definition lists (the ; and : markup). ("Eventually" means "not even close to soon", in this case.)

Separately from that, it would probably make sense to update the dab-page guidelines to discourage this style of formatting, and to add it as a cleanup item to CHECKWIKI and AWB scripts. Whatamidoing (WMF) (talk) 03:13, 24 December 2015 (UTC)

As someone who operates in the article space which tends to start every article with

((use Australian English)) ((use dmy dates))

it is really annoying when Citoid produces non-dmy dates in such articles. Could Citoid be made a little smarter to detect the presence of the ((use dmy dates)) in the article and provide DMY dates please. Again, it's the kind of thing that will just create conflict between the VE users and the rest of the Australian community ("messing up articles with VE").

In the source editor, I don't have a problem if some tool inserts non-DMY dates because I have the gadget installed to allow me to convert "all dates to DMY" but that gadget does not show itself in the VE. So when I use Citoid, I have to switch into the source editor, and then click "all dates to DMY" to fix the Citoid. Or else allow the DMY-fixing gadget to work with VE.

As someone who is trying to make VE my default, I find myself constantly having to switch to the source editor to fix things I just cannot do (or cannot easily do) in VE. Kerry (talk) 21:17, 22 December 2015 (UTC)

It probably can't be done in the citoid service; it definitely won't be done (devs have already refused). However, there's a discussion at the citation templates to make the templates properly respect those standards, which solves the problem here while still making it safe to copy citation templates between Wikipedias (some of which have different stylistic rules). Whatamidoing (WMF) (talk) 03:16, 24 December 2015 (UTC)

Hi there,

On this test template (Template:Infobox country/Sandbox 1),

I am unable to translate the template row labels, such as:

Flag
Seal
Anthem
Status
Capital
Largest Village
Official languages
Ethnice groups
Denonym
Sovereign State
Government

President

Governor

Lt. Governor

Delegate

Legislature
Area

Total

Water %

Population

2015 Estimate

2010 Census

Density

GDP

TotaL

Per Capita

HDI
Currency
Time zone
Calling Code
ISO 3166 Code
Interent TLD
Website

I am trying to get those row labels translated into another language for use on another Wikipedia language edition.

Could you show me how this could be done using Visual Editor? That would save me a lot of time instead of drilling down and manually editing the source code. Thanks. --Philip J (talk) 21:38, 22 December 2015 (UTC)

I'm sorry, Philip J, but templates cannot be edited in the visual editor. The only way to translate a template is to translate the raw wikitext-based code directly. Whatamidoing (WMF) (talk) 03:18, 24 December 2015 (UTC)

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

In the references part of the article, somebody wrote down "slob on my knob". I'm not sure that that is appropriate or related to the article. I'm not sure how to delete that part so I was wondering if you could.

Random15679 (talk) 20:51, 22 December 2015 (UTC)

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

By the way my last comment was on the article Law of April 6, 1830.

Random15679 (talk) 20:57, 22 December 2015 (UTC)

This was fixed by another editor. Whatamidoing (WMF) (talk) 03:20, 24 December 2015 (UTC)

Hi, please see the VE-related thread on this talk page: Talk:Albert_Rees (It was posted to this page per the editor's policies.) Apparently, VE extracts ASINs automatically from Amazon pages. This is normally a desirable feature, but apparently when a valid ISBN also exists on en.wikipedia only the ISBN should be reported, whereas fr.wikipedia prefers both. I refer you to the page: Talk:Albert_Rees--Dk3298371 (talk) 06:50, 25 December 2015 (UTC)

In fact, fr.wiki also advises against using ASIN when other non commercial IDs are available, see fr:Modèle:Ouvrage and the description of the asin parameter. --NicoV ^{(Talk on frwiki)} 11:10, 25 December 2015 (UTC)

Hmmm, then it would appear that the behavior I experienced with VE is genuinely undesired. If someone now turns VE into a bot, then we can indeed have the Wikipedia bot edit war I described on the above referenced talk page. Since Wikipedia text is being used to train AIs like Watson, could this prospective bot war edit indeed be the beginning of the end of humanity, as my earlier comments on that talk page suggested? :)--Dk3298371 (talk) 17:25, 25 December 2015 (UTC)

It should be easy to keep the metadata and suppress the display in the template. Whatamidoing (WMF) (talk) 23:12, 25 December 2015 (UTC)

See this edit, where whole sections have been put into a single line by VE (including the titles of several sections). Also, look at the mess done on the categories. --NicoV ^{(Talk on frwiki)} 11:10, 27 December 2015 (UTC)

Thanks for filing that bug report. Whatamidoing (WMF) (talk) 05:41, 28 December 2015 (UTC)

Thanks for the bug report. I've left some notes on the bug report. Let us track this there. SSastry (WMF) (talk) 16:52, 28 December 2015 (UTC)

In this edit, I added the last body paragraph in Westwood House by a copy-and-paste from a paragraph from Westwood, Queensland (both were opened in the VE) which carried over two citations. I then fiddled a bit with the wording so it flowed better in the context of the Westwood House article (but this did not affect the citations in any way). I saved Westwood House and was surprised to see that the citations I had added to the article (which were the last citations in the body of the article) were numbered [1] and [2] while the remaining citations (all earlier in the article) were numbered [3], [4] etc. I opened the Westwood House article again in the VE and saw the citations numbered [1], [2], ... through the article and then at my new final paragraph [1] and [2] were repeated. (Note there was no relationship between my two citations and any other citation in the article -- no re-use etc). I went back to article mode and this time the citatons seemed to be numbered normally [1] [2] etc through the article as you would expect. But when I opened it again in the VE, the numbering was back to [3] [4] .... [1] [2]. I am not sure if my initial article view after the edit is reproducible (as now it shows the numbering correctly) but my opening of the article in VE consistently numbers the references wrongly. I am aware we have a problem with numbering citations when some of them appear in infoboxes etc and this article does have one citation in a photo caption (nothing to do with my edits), but the citation-in-a-box problem just impacts the incrementing of the citation numbers. I've never seen it start reusing the citation numbers. When I looked in the source editor, I notice that the first of my copy-and-paste citations has name=":0" and I am wondering if somehow this is the culprit? Kerry (talk) 00:25, 27 December 2015 (UTC)

I then experimented with removing the citation in the image caption to see if that was the problem. However, it did not change anything. In the VE the article still has citations numbered [1] [2] ... and then [1] [2] repeated in my new para. Kerry (talk) 00:32, 27 December 2015 (UTC)

Using the source editor, I then removed the name=":0" from the citation carried across from Westwood, Queensland, thinking that must be cause of the problem but nothing changed. When I open the article in VE, I still see my two citations at the end of the article numbered [1] and [2]. Looking in the source editor, I notice that while my copied citations areusing <ref></ref> tags, while all the other citations in the article use ((sfn)). Maybe it is the two different citation styles that is doing something weird in the VE? Kerry (talk) 00:41, 27 December 2015 (UTC)

((sfn)) is the source of the mismatch. Basically, this is the same problem as refs in other templates being counted separately. Whatamidoing (WMF) (talk) 05:37, 28 December 2015 (UTC)

It's been known for some time that VE doesn't properly handle footnotes within a template. Another common place where this problem occurs is with infoboxes, which are templates - the more important articles almost all have infoboxes, and editors are encouraged to add citations to all content, infoboxes included, so the problem is only going to get worse. Currently #5 at Wikipedia:VisualEditor/Known problems.

I've posted a complaint at Phabricator that this issue should be given considerably higher priority. Currently it's unassigned, which means it's not being worked at all. And yes, if the above seems familiar, it's because it's repetitious - see Wikipedia:VisualEditor/Feedback/Archive 2015 3#Inline ref numbers counted badly-- John Broughton (♫♫) 00:50, 29 December 2015 (UTC)

I stumbled onto this real "new user with VE" example via my watchlist. The backstory (via the Teahouse) is that this is an article about her grandfather John Richardson Wigham and the photo provided is of someone else. She has uploaded a real photo of him to Commons and is now trying to replace the photo in the infobox. She would appear to have copied the markup offered by Commons to "Use on a Wiki" (which would be perfectly correct if she was a source editor user). But watch what happens as a VE user.

Step through the story starting with [19] with this first edit where she pastes in the markup. But that doesn't work, so she removes it. Then she realises she's got to do something to the infobox, so she would appear to have managed to replace the infobox with the markup. Then she manages to somehow manglethe EngvarB template into her image markup. She realises she has deleted the infobox and tries to reconstruct it (without knowing about the infobox template). The sequence of events is then interrupted by her photo being removed from Commons for not having the right permissions. Fortunately the ensuing dialogue at the Teahouse results in someone else cleaning up the mess.

It's a good example of the use case "new user wants to put a photo in an article" and/or "new user wants to put a photo in an infobox" and how the VE just can't do it for them. This user never discovered "Insert media" and even if she did, she could not have used it on an infobox. Kerry (talk) 22:59, 28 December 2015 (UTC)

Factoid: ((Infobox)) is used 2.3 million times in the English Wikipedia, often as part of another template, such as ((Infobox scientist)), which is in the John Richardson Wigham article. -- John Broughton (♫♫) 00:59, 29 December 2015 (UTC)

so the editing of a significant number of articles is affected. Kerry (talk) 01:38, 29 December 2015 (UTC)