This is an archive of past discussions on Wikipedia:VisualEditor. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current main page.
Visual Editor
Having learned how VisualEditor works, the problems make far more sense - it has to convert Wikitext to a carefully-formatted and marked-up intermediary (based on HTML, though this is largely because it simplifies displaying it in the browser), in a reversible way, with a lot of tests to make sure it only changes the bits that were actually changed. Parsoid really is an ingenious reinterpreter, but it was bound to have some problems.
Also, the lack of features also makes sense - everything's basically handled as a modular expansion, apparently, even bold and italic are, effectively, in the same modular coding. They needed to get the base right, then they could begin rushing into other features.
In short, I'm... just going to retract 99% of everything I've said about VisualEditor, and apologise. It's a very, very clever project, and, if it wasn't explained very well, well, time to move on from that.
My only request to the VisualEditor team is to please get those videos up as soon as possible. Everyone needs to see them. Just having VisualEditor explained, in full, makes the whole thing make sense in a way that it didn't before, and makes me hugely optimistic for its future. Adam Cuerden(talk)15:27, 9 August 2013 (UTC)
Hi again Adam, it's great to hear you're having a good time there. I also hope to have those vids up on Commons ASAP. I think a Parsoid presentation is scheduled for tomorrow, if I read a related tweet correctly?, in case, you might want to be there as well. Also, can you please tell VE folks that I miss them and am looking forward to having them back, although I know they needed such a break? Thanks :) --Elitre (WMF) (talk) 15:44, 9 August 2013 (UTC)
I'll definitely tell them. I just wish I didn't feel so stupid about this, now that I understand it. Missing features make a lot more sense when you learn it's a modular system - they missed some key ones, yes, but the backbone makes sense; and a lot of strange features, like "Why use constant forms to fill out even simple templates?" make a lot more sense when you learn "Ah, so that's a default handler that at least works in all cases, and improved handling can be added later in specific cases where it's appropriate." And the details of converting from wikimarkup into a carefully-constructed, heavily-annotated HTML-based system that can both be displayed (hence HTML-based) and can be used to flawlessly reconstruct wikitext is actually incredibly ingenious, and explains some bugs that, while annoying, were almost certainly unavoidable when large-scale testing something that complex.
(edit conflict) I do have to say that when I saw you'd posted on this page Adam this wasn't what I expected to read :) Thank you. Say Hello to the VE team for me as well. Thryduulf (talk) 15:53, 9 August 2013 (UTC)
"Not understanding" can definitely happen. "Refusing to understand" is different and I don't think this is what happened here, so, it's ok. (Bonus if you post a pic of yourself in a VE shirt or near someone wearing it!) --Elitre (WMF) (talk) 15:58, 9 August 2013 (UTC)
noframe Here's a picture of Adam in a VE T-shirt. I took it after teasing him that it must have been the gift of the shirt which won him over. Me, I attended the same presentation and was also impressed by the concepts and the demo of the Google maps add-in. But then I tried working on a new article later that evening with VE and found I couldn't save my work. Perhaps I need a T-shirt to be converted too. :) Andrew Davidson (talk) 09:47, 12 August 2013 (UTC)
As I've long said, and discussed with a couple of WMF staff, I think the biggest problem with the whole VE rollout, development, basically everything about it (and other recent software deployments), has been the atrocious communication between WMF/developers on one side and users on the others which has left users feeling like they're being ignored and their views don't count. I'm a little reassured that WMF are somewhat aware that they have communication issues but still aren't very reassured by what they're doing about it. Dpmuk (talk) 17:11, 9 August 2013 (UTC)
One thing I also learned is that the Wikipedia development staff massively expanded this year. It's why a lot of new things are suddenly coming in, which is great, but well, I'm not entirely surprised that the first really big launch from what's basically a new team was a little rocky. Adam Cuerden(talk)01:48, 10 August 2013 (UTC)
I'd say that the biggest problem with V/E's rollout has been that it was rolled out too quickly and as a result the developers have not been able to keep up with the rate at which bugs have been found. Testers like myself then wait months for the bugs that we reported to be fixed, and that makes it a very difficult uninspiring project to engage with. In the meantime training sessions take place in which trainers have to show people how to opt out of V/E as the first thing in the lesson, and huge numbers of newbies are burned, some fairly mildly by just finding that editing Wikipedia on a not particularly old pc is a mind numbingly slow experience tat they probably won't repeat. Others get warned for vandalism when actually it was v/e damaging their edits. These are the people we should really regret losing as they will be justifiably pissed off with us. The aim of V/E is great, if only it could be switched off until it is ready for another round of testing. As for communication, bugzilla is a barrier, we really need to replace it with something on meta, within SUL, something that gets the developers on wiki. I never doubted that the problem it was intended to address was important and worth trying to fix. As to whether it can be fixed, some of the damage of the early rollout is not easily repaired. Obviously some newbies will have been lost to us. Perhaps the slowness can be fixed, though it has been months now, at worst we could just park it for a few years and wait for most of the world's current PC to be replaced. ϢereSpielChequers06:58, 11 August 2013 (UTC)
Actually, one of my best memories of Wikimania is trying to use VE, hitting a problem where I couldn't figure out how to do references, asking James about it, and ending up spending about half an hour in a rather productive discussion of design interface ideas with him. — Preceding unsigned comment added by Adam Cuerden (talk • contribs) 2215, 13 August 2013
Keyboard shortcut to show the changes does not work any more
The following discussion is marked as answered. If you have a new comment, place it just below the box.
I use keyboard shortcuts to edit, save and preview an article or to show its changes. For instance, to preview I use <shift><alt>P. The shortcuts still work, except <shift><alt>V (show the changes), which stopped working when the Visual Editor was introduced: currently, <shift><alt>V simply positions the cursor on the "Show the changes" button. JmCor (talk) 03:49, 10 August 2013 (UTC)
To duplicate:
Open an article in the edit mode; do some changes; try <shift><alt>P (works), then and try <shift><alt>V (doesn't).
Operating system
Windows 7
Web browser
Firefox
Site
Workaround
Use <shift><alt>V to position the cursor on the button then click the button.
I have the same problem in Safari 6 and Firefox 22 on a Mac. In Safari, the problem goes away when I tick the prefs switch to disable VisualEditor; in Firefox it didn't, but that may say more about the cache or something than about the actual status of the feature. Whatamidoing (WMF) (talk) 20:09, 12 August 2013 (UTC)
I've just tested and disabling VE on Firefox 23 on Linux does enable the shortcut. It also works in Konqueror, which is not supported by VE. I've updated the bug above. I didn't think to test that earlier, thanks! Thryduulf (talk) 20:37, 12 August 2013 (UTC)
References certainly should be editable. Looking at your contributions it seems that you were trying to edit LeGarrette Blount and that article works for me, including the references. Could you be more specific about what you were trying to do, what didn't work and what browser and operating system you are using? Thryduulf (talk) 21:14, 10 August 2013 (UTC)
Many editors using VE instinctively try to edit the reference list at the bottom of an article. That can't be done. Looie496 (talk) 16:06, 11 August 2013 (UTC)
That can't be done with the classic editor either, it's just not the way references work. You can edit each reference by clicking on its number in the text instead, and it's far easier to do that with VE than with the classic editor since it saves your time when looking for it :) --Elitre (WMF) (talk) 16:11, 11 August 2013 (UTC)
Yes, but in the classical editor the temptation is not there, because when the classical editor is active all you see when you look at the References section is {{reflist}} or something equivalent. In VE you can actually see the entire list of references -- and you can't directly see them in the body of the article. Looie496 (talk) 16:16, 11 August 2013 (UTC)
Ok, but one should actually read the User Guide to learn more about references, where this all is explained. Not sure this can/should be done, but we might also investigate the possibility of asking for the VE link to be disabled for specific sections. --Elitre (WMF) (talk) 16:21, 11 August 2013 (UTC)
To alleviate any possible misunderstanding here, I'm not the slightest bit confused about this myself. I'm simply pointing out that a new editor using VE who wants to edit a reference will naturally guess that the way to do it is to "visually edit" the reference where it appears. It would probably be a good idea for VE to pop up a special message when a user tries to edit a "reflist" template. Looie496 (talk) 16:36, 11 August 2013 (UTC)
Yes, I was just thinking the same - a message explaining how to edit references would probably help. I've filed T54736 as an enhancement request for this message. I've asked for the text of the message to be settable on-wiki but do say if you can think of a good default/initial wording (I'm not good at that). Thryduulf (talk) 21:47, 11 August 2013 (UTC)
Elitre, I love you and all of the VE folks for your work on the editor and on this page, but I believe I must say this: when it comes to usability issues reported by newbies, "read the manual" is a fundamentally unhelpful response. Newbies, who possess the very instincts that VE should be designed to facilitate, never read the manual. If users are required to read the manual before being able to perform tasks that they feel they instinctively know how to do, the interface is not designed correctly. (And I would say this in the context of any newbie-oriented interface, not just VE.) <3 ♥ Cryptic C62 · Talk23:06, 11 August 2013 (UTC)
One - far more intuitive way - to edit footnotes would be for VE to make each footnote number a way to edit that footnote (by clicking on the number). Those footnote numbers would be outside of the reflist template, and (ideally) would be shown with a different background color. They would also react differently than the rest of the footnote section when the mouse pointer is put on them.
It's true that there is certain logic to editing a footnote by going to to the footnote number, in the body of the text, but it's more logical to try to edit a footnote at the point where the text of that footnote is visible. Think of this from the editor's viewpoint - s/he is reading the article, sees where a footnote can be improved or needs to be replaced, clicks on the section link for VE (or, less likely, scrolls to the top of the page to click to start editing in VE), sees the footnotes displayed exactly as they were in reading mode (hopefully), and starts to make the improvement by (yes) clicking on the footnote.
I also note that "[Esc]" should unselect the reflist template, if that's mistakenly selected. Instead, the editor has to click outside of the template area in order to unselect it. That's not anywhere near as intuitive as [Esc]. -- John Broughton(♫♫)01:52, 12 August 2013 (UTC)
Curiously Elitre's read the manual conflicts with JDF's "In general, if you have to prompt a user with text telling them what to do, your interface has failed." I tried to get some sort of text description explaining how to use references into the dialog boxes but it was shot down by JDF pretty swiftly in T54250.--Salix (talk): 08:53, 12 August 2013 (UTC)
So why not make the reflist editable? As just about every object you see on a page is directly editable with the VE, of course having the reflist not editable is counter-intuitive. Displaying a message is a workaround, but VE could also be much more helpful by just letting you edit the references. Surely needs this some work and fleshing out how to exactly do this, but I am sure this is more helpful than adding in messages. --WS (talk) 10:53, 12 August 2013 (UTC)
I'd suggest popping up a note telling the user what he or she is doing at least the first time, though. Something like "This reference is used to document the source of text in the article. You can also edit it by clicking on the number after the text. Please make sure that you don't accidentally break documentation with your edit. Thanks for your work!"
A good point, I've copied those comments to T54750, although I don't think "documentation" is the right word - to me documentation would be something that explains the referencing feature rather than part of the feature itself. Something like "verifiability" might be better but I can't immediately work that into a sentence that is both concise and meaningful. Thryduulf (talk) 15:42, 12 August 2013 (UTC)
Here's my suggestion for a message: This list of references is automatically generated and cannot be edited directly. If you would like to change the content of a reference, click on its number where it appears in the body of the article.Looie496 (talk) 16:04, 12 August 2013 (UTC)
A good suggestion that I've added to T54736, where I have also suggested that the backlinks should take you to the position of the reference, as they do in article mode, while remaining in edit mode. Thryduulf (talk) 16:09, 12 August 2013 (UTC)
My suggestion was not meant to be "have them RTFM" :) but merely, chances are that at least some of them will a) already know that's not the way refs work b) learn this from the guide. I think/hope someone is working on a guided tour about VE ([1]), which is probably a good place to put this info in. We are using many messages, and I don't think this means we failed, we just really need people to see how/why some things are also working differently now. I guess this is the first time I read concerns about this specific issue, but if many people share them, I'll be happy to help you get the solution you think it is more appropriate. Thanks for weighing in about this :) --Elitre (WMF) (talk) 16:12, 12 August 2013 (UTC)
Truncated 1st launch message.
The following discussion is marked as answered. If you have a new comment, place it just below the box.
I just checked out Visual Editor as an IP user —didn't feel like logging in, just clicked the "edit beta" option by a section heading. I was greeted with a small two line pop-up message window which read:
This is our new, easier way to edit. It's still in beta,
which means you might find parts of the page you
That's was it in it's entirety. (Well, excepting a heading which was in image format rather than select-able text.)
Re-scaling my page view (via Chrome browser via Bodhi Linux) re-sized but brought up no further text.
Hmm, I just checked my settings and Chrome's default text size was set to "very large". That may have been what caused the text to display incompletely. (I've mostly been using Firefox lately, 1st I've launched Chrome in awhile.)
I seem to have figured it out—narrowed it down to local user settings—but I'll post anyway on the chance it may help someone else.
Thanks for the report. This is a known problem, tracked as T54667 but at the minute it remains unprioritised so I can't give an estimate of when it will be fixed. Thryduulf (talk) 09:42, 12 August 2013 (UTC)
Can't add new material to a page after deleting the whole content
The following discussion is marked as answered. If you have a new comment, place it just below the box.
I wanted to delete the whole content of a test page and add something new. This is the page, but I get the same effect on other pages. Steps to reproduce:
Click "Edit beta"
Right-click, select all
Press "Delete" (or "Backspace") to remove the whole content.
Now clicking does not place the cursor on the page, and typing does not add content.
Removing line above header "de-headers" it; lack of "undo" facility
The following discussion is marked as answered. If you have a new comment, place it just below the box.
This is not a contrived test, I encountered it in "real life" as a instance of VE not behaving as I expected.
Steps to reproduce:
Start with this test page. We want to remove the line just above the second header.
Click "Edit beta"
Place the cursor at the end of "Demonstration line for test" and sweep left to select the whole line
Press "Delete" to remove the line.
That leaves a blank line, so press "Delete" again. The blank line goes, but "Second header" ceases to be a header.
Now one would hope to reverse the last step by pressing "return"; that restores the blank line, but does not restore the header.
As a general comment, using VE I feel the lack of an "Undo" facility; when one has made a mistake, there often seems no alternative to going back to square one and starting the whole edit again.
Commenting now the last line: there is an Undo facility. There's a button and a common shortcut for that. Don't they work for you? Thanks, --Elitre (WMF) (talk) 17:23, 12 August 2013 (UTC)
Facepalm . Quite right; they do for me, too. I should have RTFM. Still, the de-headering is disconcerting, and I would have expected "Return" to reverse it. JohnCD (talk) 17:46, 12 August 2013 (UTC)
I've had related problems to the de-headering but more to do with cut and paste. There is a big difference between selecting a line when the selection region goes all the way to the right hand side or to just after the last character of a line. T35105 has a couple of cases where pasting has a different results depending on the exact selection region.
If you select just the text so the selection region end just after the the last 't' deleting works fine. As does cut and paste preserving any rich text like links. (Looking at the clipboard its just a <span>). If you select so it goes all the way to the RHS deleting will remove the following header (The clipboard here is <p>...</p><br> block level elements).
I've created another test file. User:Salix alba/VE test with a number of different heading levels. What happens is that if you select a whole line so selection region goes all the way to the right hand edge and delete the following header gets changed to the heading level of the section just deleted. So with an <h3> followed by a <h4> deleting the <h3> changes the following heading to be <h3>! You can also change paragraphs to headings and heading to paragraphs just by deleting the line above.--Salix (talk): 20:46, 12 August 2013 (UTC)
T47132 discusses this. There, James comments that instead of displaying the warning, VisualEditor could: "auto-fix for them (insert a "== References ==\n" section just above the categories), though this (a) sucks, (b) enforces a particular wiki's style on other wikis in code, and (c) would be difficult to internationalise"
He does not elaborate on why it "sucks", but b and c are obviously valid points. This is not to say however that these problems are not insurmountable - if you have any ideas please do share them, either direct at bugzilla:45132 or via here if you prefer. Thryduulf (talk) 15:51, 12 August 2013 (UTC)
Putting {{reflist}} above the categories would work for other languages wouldn't it? Having a heading is nice, but not having one doesn't cause an error. ϢereSpielChequers16:22, 12 August 2013 (UTC)
"Above categories" means "below navboxes, ==External links==, ==Further reading==, and other end-of-page material". You could do it, and it would work well for many projects, but it would produce MOS violations here. Whatamidoing (WMF) (talk) 20:16, 12 August 2013 (UTC)
Surely b and c can be resolved by having some wiki-specific settings somewhere on the wiki itself that are respected by the VE? So it could simply be specified which sections and/or templates go before or after the reflist and it would be simple to adapt that for other-language wikis. --WS (talk) 11:41, 13 August 2013 (UTC)
c should be easy to resolve with a couple of MediaWiki namespace pages where the names of the section and reference template are read from. b would be trickier as it would need to account for many combinations of various acceptable section names, templates (incl redirects) and other things that could appear on the page. It would also need to be done in such a way that it didn't break if the page wasn't properly formatted at the start of the VE edit. Thryduulf (talk) 12:03, 13 August 2013 (UTC)
I think displaying a warning would make more sense and be more flexible. Specifically, I think it would make more sense to display a warning when you try to save the page, e.g., "You have ref tags but no way to display them. Before saving the page, would you like to add a ref list to display them? (Save anyway) (Go back to editing)" Then you get an opportunity to add the reflist before you save, rather than the scary red warning after you've finished the edit. Whatamidoing (WMF) (talk) 17:24, 13 August 2013 (UTC)
Are you guys deliberately annoying users?
Before it worked to disable VE by adblocking it. This completely removed the "Edit source" cruft etc. for IP-editors. Now for some reason, although the VE obviously doesn't work when it's blocked, the annoying labels are still showing up. This seems to have been done deliberately to sabotage this method of disabling VE for non-logged-in users. And I find it completely distasteful if that's the case. Is it really so hard to again make the appearance of the VE-related cruft dependent on whether the VE-module is loaded or not? 86.30.135.155 (talk) 20:58, 12 August 2013 (UTC) (disgusted editor)
Both 'Edit source' and 'Edit' are showing up, and that's both at the page level (at the top bar) and for each individual section. It adds a lot of noise to the pages. Before, (a few days ago? a week? 2 weeks at the most?) when adblocking the Visual Editor module, everything returned to how it was before, with just one 'Edit' in both places, which took you to the standard (non-VE) editor. I hope this wasn't done deliberately and can be rectified again. Browser: Chrome on Mac (also Chrome on Windows). 86.30.135.155 (talk) 21:04, 12 August 2013 (UTC)
The labels were changed to put the wikitext editor first and make it clear VE is beta. Looking at Wikipedia:VisualEditor/Opt-out it seems that AdBlock can add a filter to block "modules=ext.visualEditor". This might be a more stable solution.--Salix (talk): 21:09, 12 August 2013 (UTC)
Salix, that's exactly what I was doing (and what worked before). It used to show "Edit Source" and "Edit" (can't remember which order), for each section and at the top, but after adblocking it, it only showed "Edit" which took you to the standard (source) editor. But with some recent change, it now shows both "Edit source" and "Edit" (in that order) for each section, and in the top bar. 86.30.135.155 (talk) 21:15, 12 August 2013 (UTC)
It's one of those problems with using an unsupported hack: it no longer prevents the tags from being displayed. It still prevents the editor from being loaded.—Kww(talk) 23:04, 12 August 2013 (UTC)
That will stop the code loading and hide all VE related elements. It will still say "edit source", rather than just edit, you would need some local javascript to fix that.--Salix (talk): 07:32, 13 August 2013 (UTC)
No, this wasn't deliberately done to annoy people; quite the opposite. We changed button positioning and labelling to help users, and it seems to have had that effect; I'm sorry that it didn't take into account an unsupported, client-side tweak to the interface, but many of our changes are not likely to. Okeyes (WMF) (talk) 07:36, 13 August 2013 (UTC)
Ok, it works again now with Salix's tweak above, please could you try to keep an easy way of blocking this for IP users? I like to edit Wikipedia and probably have several thousand edits under my belt without being logged in, and I'd like to be able to continue to do so, as I'm sure many others feel as well. 86.30.135.155 (talk) 12:39, 13 August 2013 (UTC)
Given how much of the staff is traveling at the moment, and how long it will take them to read and understand that page, I would not expect any significant response any time soon. Whatamidoing (WMF) (talk) 17:31, 13 August 2013 (UTC)
It's pretty easy to understand and implement: flip the default setting for VE to "off" for all editors, allowing those that choose to reenable it to do so. Set up some kind of cookie-based arrangement so that IP editors can ask to be allowed to use VE. A few hours work at most.—Kww(talk) 18:11, 13 August 2013 (UTC)
In Television series and Manga.
The following discussion is marked as answered. If you have a new comment, place it just below the box.
If you can't fix these things yourself, then you should normally make a note on the article talk page. In this case though "Lucitania" is an uncommon spelling and so I was able to find and fix it in three articles (although there are a couple of places where this spelling is correct). Thryduulf (talk) 10:47, 13 August 2013 (UTC)
Tags added by editor
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Hi, do not know what is going on with this edit but the editor appears to have top/tailed the article with <embed type="application/x-datavault" width="0" height="0" /> for some reason. Keith D (talk) 10:53, 13 August 2013 (UTC)
When editing a reference, there is no indication at all if it is used multiple times throughout the article. This makes it very easy to screw up references, e.g. when you replace a ref for one sentence by changing it and it gets propagated throughout the article. WS (talk) 11:45, 13 August 2013 (UTC)
Not sure with how much ease, Edit Filter also can be used for this issue,but if issue is pointed out, then edit filter managers need to be ready to fight it out till issue is fixed through software.
I'm using Chrome and I right clicked to corred "32 GB" (it should be "32GB"), and it duplicated "GB". It resulted in displaying "32GB GB". Eduardo06sp (talk) 02:17, 10 August 2013 (UTC)
Looking at the user's contributions, I'm guessing the issue was here. I'm not sure I see a problem with that edit, but i'm guessing that's the article. --j⚛e deckertalk16:39, 11 August 2013 (UTC)
Ah right, it could be that the issue was with the formatting as the numbers were, eg. 32 GB. Firefox doesn't regard that as a spelling problem so I can't reproduce the issue. Can anyone with Chrome see if they can duplicate it, and whether this occurs only in VE or elsewhere too (the latter would probably make it a Chrome bug rather than a VE one?). Thryduulf (talk) 21:25, 11 August 2013 (UTC)
I tried with both Chrome and FF but I could not see that as something that had to be fixed, so I just removed the spaces, but the previews were ok. It took a while to get to the preview, though :/ --Elitre (WMF) (talk) 08:29, 14 August 2013 (UTC)
Wikitext markup detected message
The following discussion is marked as answered. If you have a new comment, place it just below the box.
The wikitext markup detected message that appears when you type wikitext in the VE, doesn't disappear when you remove the wikitext. WS (talk) 15:45, 12 August 2013 (UTC)
T53701 is a request for the notification to be closed when the markup is removed. It's only regarded as a low priority though, so for the meanwhile you will need to continue to click to dismiss it (or not ever wikitext in the first place, but I know that's not easy!). Thryduulf (talk) 16:24, 12 August 2013 (UTC)
VE could be programmed to determine if a user has removed the wikitext. In theory it could look for the protective nowiki tags it uses to isolate added wikitext, and if seeing none, clear the warning. But that requires a different programming approach - to check, after each keystroke, whether nowiki tags still remain; and, of course, not to count nowiki tags that existed before the edit began. (These are rare on article pages, but VE is being designed to edit all types of pages except Talk.)
Rather than focus on improving this warning, a better direction to go would be for VE to be able to convert wikitext to its equivalent in VE. Thus if one typed [[New York City]], for example, VE would convert that to its format for an internal link. This is fairly straight-forward, programming-wise: after VE adds a closing nowiki tag for some text, it would examine it for conversion possibilities: external link? internal link? footnote? template? (But now complications set in with regards user interaction: Should VE warn the user, given that he/she has done something constructive, and may be quite aware that he/she used wikitext? Should the warning be of the type "Please don't do that"?) -- John Broughton(♫♫)16:26, 12 August 2013 (UTC)
It wasn't obvious to me how to get rid of the notice. In fact, it popped up and partially covered the "save" button in such a way that when I tried to click save, nothing happened, and the notice was still there! For a few seconds I thought I wouldn't be able to save my changes at all, even though I'd removed the wikitext. Fortunately I kept clicking nearby (in frustration) and the notice disappeared. But I would have been helped if there had simply been a "dismiss" button, or something similar, that indicates you should click on it to dismiss it. This wasn't obvious to me. Mark M (talk) 13:18, 14 August 2013 (UTC)
Yes, T54386 requests that the wikitext warning and similar popup boxes should have an indication they can be closed - the method suggested is an X in the top right corner rather than a button. I've copied your comments to the bug report so hopefully it shouldn't be too long before its fixed (as I don't imagine it's complicated), but in the meanwhile you can continue to click anywhere on the message to dismiss it. Thryduulf (talk) 13:27, 14 August 2013 (UTC)
Is this a comment about VisualEditor or about a specific article? If the former, then you've posted it in the wrong place and you need to ask the question on the article talk page. If this is about VisualEditor then you are going to need to be more specific, as I don't understand what you are asking? Thryduulf (talk) 20:19, 13 August 2013 (UTC)
Isn't that the point of overwriting? :) If you select a/many word/s and then keep typing, your text is replaced. Or, you probably hit Insert key and maybe did not realize it? Thanks, --Elitre (WMF) (talk) 08:39, 14 August 2013 (UTC)
Galleries unsupported
I know there's a lot of new gallery functionality coming in (which looks amazing!), so I'd understand if support is waiting for that, but at the moment, galleries are completely uneditable.
Basic functionality I'd expect might include:
Dragging images to different parts of the gallery, preferably by a simple click and drag.
Adding and removing images
Caption editing/addition/removal.
If moving images is as easy as dragging them into position, adding images can probably reasonably add to the end.
To allow the gallery itself to be moved, I'd suggest that clicking on the gallery adds a bar at the top (only while it remains the focus, of course), labelled something like "click and drag here to move gallery". (If that's unclear, I could make a mockup), plus a dropdown box for any other actions that might be needed, sort of like the top of a Windows, well, window. One thing VE currently doesn't do enough of is temporarily tweaking the display of an element being edited to make it easier to interact with for editing, but I don't see a way to get the intuitive editing you're looking for without some movement towards that. Adam Cuerden(talk)22:40, 13 August 2013 (UTC)
It's a little concerning that that bug is opened over 6 months ago; at the same time, though, drag and drop support is fairly complex coding given the framework, so it's understandable. Adam Cuerden(talk)09:30, 14 August 2013 (UTC)
There are a whole host of issues related to extensions which need to be implemented (T48803). I suspect these are kind of a wish list of what needs to be done at some point, so more feature requests than bugs. So its good the list is established but other core issues will take precedence.--Salix (talk): 09:56, 14 August 2013 (UTC)
Also, to do galleries at all well needs good drag and drop support (at least, both James and I have said so) - something nothing currently implemented uses. Whilst it'll add a lot of functionality when VE supports it, I'm presuming it does not at this time? Adam Cuerden(talk)11:56, 14 August 2013 (UTC)
I believe that you're right about drag-and-drop not existing yet.
Good support for galleries (which they're definitely going to want at Commons, even if they're not so widely used here) would also let you control the number of items per row and the size of the images. Whatamidoing (WMF) (talk) 17:31, 14 August 2013 (UTC)
Indeed, but that could be done with a drop-box in the corner of the bar you use to move the gallery. It's advanced functionality, and, whilst there may be places we want to make it supereasy, for Wikipedia, we probably want to prefer consistency to encouraging excessive customization. That said, Wikimania announced some really amazing new gallery tools, so perhaps it's about to get a lot more complex. Adam Cuerden(talk)20:48, 14 August 2013 (UTC)
User:Martina2504, is your comment related to the galleries' issues? I don't think so :) Anyway, you should be able to see an edit summary box, and a particularly visible one!, it is prompted after you click "Save the page" (also, the talk page is available as usual for further commentaries). Can you check? Thanks. --Elitre (WMF) (talk) 08:45, 14 August 2013 (UTC)
formatting bar should scroll with the page
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Currently, when you want to edit the format of text that exists far down on the page, you must scroll down, select it, scroll back up, change format, scroll back down to make sure it looks right, etc. My recommendation is to simplify the workflow by having the format bar scroll with the user in some form (or, alternatively, have a format pop up menu of sorts next to the selected text). 67.183.110.137 (talk) 07:17, 14 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Please note you are using wrong photograph it belongs to me totally different OM Sharma please delete this photograph
OM Sharma 86.19.108.234 (talk) 19:03, 14 August 2013 (UTC)
This page is for providing feedback on VisualEditor, our new user interface. If you have feedback on a specific article, please leave a comment on that article's discussion page. --Cryptic C62 · Talk20:07, 14 August 2013 (UTC)
Template moved inside heading
The following discussion is marked as answered. If you have a new comment, place it just below the box.
With this edit, the {{-}} was moved from the bottom of a section into a heading, effectively yielding the HTML <h3><span class="mw-headline" id="2013">2013<br style="clear:both;" /></span>[edit]</h3> --Redrose64 (talk) 18:43, 8 August 2013 (UTC)
I can reproduce that on the article, but not in my sandbox, so it isn't just as simple as a {{-}} before a heading. I don't know what it is though. I've reported it as T54658. Thanks for the report. Thryduulf (talk) 19:23, 8 August 2013 (UTC)
@Redrose64: can you still reproduce this bug? If so, please could you say what browser, operating system and skin you are using? Ssastry commented on the bug that he couldn't reproduce it, and I can't now either (although I could earlier). Thryduulf (talk) 00:00, 13 August 2013 (UTC)
Well, I managed to achieve something similar. Rather than changing the existing header, I typed in the word 2013 and then applied the header style to it. I caught the template, too. I've updated the bug. --Maggie Dennis (WMF) (talk) 11:52, 15 August 2013 (UTC)
Adding/reusing existing reference multiple time blocks all editing until we close tab from browser
Hi,
Adding/reusing existing reference multiple time(more than 1 time) blocks all editing,until we close tab from browser,VE does not allow to even to go back and save rest of edited content.Screen simply hangs until we close tab from browser.
Facility to choose from existing references made feel wow great ! but when I wanted to add the same existing reference at multiple places and VE screen blocked all the ways and I had to close the tab from browser I came out frustrated since it did not allow me to save rest of newly written and edited content.
I select for editing method VE.>> If I select to reuse the existing reference in next para only once and save the reference it works very fine << But if I want to reuse the same existing reference in more than one place in same attempt,VE blocks all further options and screen simply hangs untill I close the tab from browser. It even does not allow me to go back and save my rest of edit attempt.(Browser Firefox latest updated)
Is this already reported ? if yes can we make atleast button goback work at our earliest and resolve rest of problem in due course.
I don't think this is any of those (the first I've just marked as a duplcate anyway), I'm about to try and reproduce this bug. Thryduulf (talk) 16:39, 12 August 2013 (UTC)
I can't reproduce that in my sandbox using the latest firefox (23) on linux [7] (all the additions were reusing an existing reference, although you wouldn't think that from the wikitext). What operating system are you using, and which reference in which article did you encounter this on? Thryduulf (talk) 16:48, 12 August 2013 (UTC)
Hello again
I use operating system windows 7. This is none of above bugs but at bug no 51689 comment-2 User John Broughton in his first point is inter mixing cited issue in wrong bug he says........Not been able to cite the same source two or more times in an article,............
I will try to give screenshot today latter, but not sure how much screen shots would benefit. I will try to repeat steps to reproduce again for win7+Firefox
Say an article has introduction and more than 2 sections.
At the end of the introductory para I add a reference and save the page it saves the reference.
I realise the same reference will work for section 1 paragraph and section 2 paragraph
So I will select to reuse the same reference for at the end of section 1 para ( if I save the page at this stage it will automatically create a reference number itself and saves the page) ; but If I do not save the page and do more attempts at subesequent para to reuse the same reference it hangs and blocks.
T53689 (comment #2) is about references created in this editing session not appearing in the list of references you can use again this editing session, which is a different issue to this one (which is about using a reference created in a previous editing session multiple times in the current editing session). Thryduulf (talk) 02:04, 13 August 2013 (UTC)
Hello again,First a thanks barnstar for all the effort you are taking to reproduce the bug for me.
I am not using any customised gadgets even from preferences window or otherwise other than hotcat on enwikipedia.(One gadget references tooltip was on en wiki, I turned off that still the problem occurs, On mr-wiki I dont use even hotcat, I faced this problem on mr-wikipedia during live edits so I did trials on en wiki my own user page.Before creating screenshots once I felt problem is fixed but when rechecked realised the problem is still there.
Feel free to use it to reinsert/repeat the reference in intro para to rest of paragraphs on my enwiki user page in single attempt.
Well hotcat shouldn't be an issue as I use that too. I've just done another test on a page with exactly one citation template and doing exactly as you did in your screenshots [9]. That didn't result in this bug either, so my guess is that it could be Windows specific, which I can't test as I don't have a Windows computer. Thryduulf (talk) 10:32, 13 August 2013 (UTC)
Okay,let me thank you once again for all the efforts you are taking, its very nice of you. Let us, we shall wait till some one with windows responds and confirms. Mahitgar (talk) 10:47, 13 August 2013 (UTC)
I tried it in Vector earlier as well (Firefox 23, Linux) as all my previous tests were in Monobook. I still couldn't reproduce it. Are you using any browser plugins? Thryduulf (talk) 13:14, 13 August 2013 (UTC)
Okay, may be I need to dig further to find if my own windows 7 setting have any problem.I can try using some other PC by tomorrow.
Because I tried on DE wikipedia user page, Win7, Chrome, Monobook, sequence after removing a-z all gadgets and disabled all browser plugins (I use only default one any way and also disabled antivirus firewall ) still I did not succeed to insert the ref second time.So may be unknown problem to my windows settings. I will keep you updated after trying from some other PCs tomorrow.
I really appreciate all the work you're going to, to help us track this down. I look forward to seeing the next update whenever you have time to try it again. Whatamidoing (WMF) (talk) 17:27, 13 August 2013 (UTC)
Hello again once more with cheers, found out the issue.Today I could sit on other comps having windows 7 and tested with Firefox and crome the above cited problem was getting repeated.Then I thought, I am may be missing some step that you all were doing,and probably that is true. At screenshots sequence 2>3>4>5 i was going back at screenshot 2 to add reference once more and that was missing an essential particular flow of apply(save) changes with step Screen shot 8 and Screen shot 9 given below
What might be the reasons you all could not reproduce this flow,possibilities may be as below, or I am still on a wrong track.
Either you were doing steps given in screenshot 8 and 9 without realising that,unaware of such requirement, I was skipping missing the requisite steps.
Or,most of you being from development side were using an older or most fresh version of VE that does not have this problem altogether which I was facing
Or in hurry, I am still making a mistake of wrong conclusions.I feel ,I still may be wrong in reporting this since nobody else pointing out this eariler on en-wiki should be a rareity.If so, sorry without qualification in advance from my side.
Or if you were using an advance version of VE not available to us yet and will be available thanks and look for the best
But if you were using same VE as I am and point number 1 is true , then may be its time to revisit and relook flow again to confirm that it will be intuititive enough to rest of newbie expected fraternity of Wikipedia.
Hi there. If you click on a single reference, as you did in ss8, you will be able to edit just that reference, not to duplicate it. In order to create more references always pointing to the existing one, you need to follow steps from ss2 to ss5, that is, using the icon from the toolbar. Even after saving the page, I still manage to add more references pointing to your first one. --Elitre (WMF) (talk) 14:29, 14 August 2013 (UTC)
Without ss8 and ss9 steps,I am still facing the issue(I reproduced the problem on my user page, at this moment again, and my other tab is hanging until, I would close it from browser).If I am the only exception to face issue then its not big issue, since I have a workable solution for myself available now.And by now en wiki has more than lacks of VE edits and if its going okay for everyone else, nothing like that.Then we can wait until some one else comes up with more details.
I'll wait for others to verify again. It is clear to me that you are able to reproduce steps from 2 to 5 since you managed to do so three times in your page (that is the only way to create such multiple references, and it works). What I don't get is how to reproduce ss6, and how 6 and 7 relate to 8 and 9 (since, as I said, the other steps don't allow reusing references). Bye, --Elitre (WMF) (talk) 15:15, 14 August 2013 (UTC)
Ya, I think certainly we wait until VE is inroduced to remaining Wikies.Because: it is user flow/behaviour while utilising and so needs other users to confirm that they too have a problem. wikipedians with languages with smaller set of info resources will tend to use same ref mutiple times,so we can also wait & lookforward to reports from mediumsize and smaller wikies.
I suppose updating related VE help sections step by step further in coming times also will help understand any missing gaps are there,and this will happen over a period of time.Again for other VE updating priorities are before you,so I agree with you, that its prudent to wait till further reports come.
I just got an unxpected result that might be related. See here. I was just trying to add the ref to the other sentences. It misplaced two copies at the start of the paragraph when I wanted one at the end of the first line of the first paragraph (perhaps I clicked too high on the top line of the edit window?). After I removed those, I couldn't add any more. Clicking the ref button did nothing. WhatamIdoing (talk) 20:43, 14 August 2013 (UTC)
Ya,I noticed if not the same but I had experienced simmiller another minor issue of generation of different ref number for same reference while giving same reference multiple times, but still need to confirm the pattern exactly when that is happening.Probably I was doing some step differently than routin.On smaller wikis like mr wiki we will be using same ref multiple times since our language info sources are limited.As and when I experience it again I will note it properly and report.
I do not know exact technical word but I suppose these issues need study of actual user behaviour and exactly which steps user is doing or missing.This shall need people who work on help pages and few field wiki academies also need to take place to bring forward some of these issues.Sorry I wrote something remotely related and more than expected.
I haven't tried to reproduce the main bug again yet, but the duplicate ref instead of reusing the existing ref is T54755 which I also came accross when trying to reproduce this bug. Since I opened the bug I've found the pattern is more complicated than I originally thought, but I haven't figured it out beyond that yet. WhatamIdoing I think seems to have found another instance of T54159. Thryduulf (talk) 08:05, 15 August 2013 (UTC)
Anonymous feedback
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Yes, I can confirm that the image still isn't being found. I think there is a bug open about selecting images by file name, but I can't find it at the moment. I've also got a vague feeling that I've seen something else about this somewhere, but I;m not sure. If nobody has beaten me to it, I'll report this next time I'm here as I'm not awake enough to do it now (also not sure if this is two bugs or three bugs). Thryduulf (talk) 02:16, 13 August 2013 (UTC)
Now at [10]. I have a few comments on this, the first is that MediaWiki search is itself slow, as we know it might take a few days or more for a new article to show up - it might be the case with pics as well? Also, I remember having issues last year with the usual Commons search not showing up all the results (Bug 37578). Thanks :) --Elitre (WMF) (talk) 08:31, 13 August 2013 (UTC)
I did a little testing. In general, images that have been at Commons for a few days are more likely to appear. But—rather frustratingly—it only seems to search for "whole words", so if you have a file name like File:5pinRelimateConnectorMaleFemale.jpg, the only way (that I found) to get that image to appear in the search results is to type the whole thing out. Just the start of it, e.g., "5pinR", produces zero search results. Just "5" might work, because just "3812" worked for File:3812b31bb051f81953e80723dab44aed2f738bd4b21cc7b6.jpg, but it doesn't seem to be possible to put in part of a sequence of letters. It doesn't also seem to be very smart about exact-phrase-only searching (e.g., if you know the exact file name, but it contains common words that appear in hundreds of images), but I haven't explored that much.
Finally, it seems to only search by filename, and keyword searching would be better, at least as an option. That could pick up translations and descriptions, and would be especially helpful with meaningless file names like that one beginning with "3812".
This is probably, however, primarily a problem with T39578, which is not VisualEditor. "GreatNurse.jpeg" gets zero hits at commons:Special:Search. The failure of the image to appear in VisualEditor is just a side effect of Commons' failure to find it at all. Searching for the exact file name produces this self-contradictory response:
So not VisualEditor's fault, but still a problem for editors everywhere. I've added a little information to the Commons bug, and asked James F to see whether this could be looked at. Whatamidoing (WMF) (talk) 18:22, 13 August 2013 (UTC)
T39578 is not about title-matching searches and only vaguely related. The real problem is T54782 which is caused by Help:Searching#Delay in updating the search index. But if you know the exact name of a file and enter it correctly, for example by copy-pasting from the file page, then you should obviously be able to add it. It's certainly either a VE bug or absurd limitation that it's impossible. A lot of images are added to articles by the uploader right after the upload. This will always fail in VE unless the upload replaced an existing file. The message you quote There is a page named "File:GreatNurse.jpeg" on this wiki is from a feature which looks up the exact searched string in a title database regardless of whether the page has been indexed by search yet. VE should do the same. mw:Help:Extension:ParserFunctions##ifexist does it, but #ifexist also returns true if a file page has been created without a file. PrimeHunter (talk) 10:58, 14 August 2013 (UTC)
It is my opinion that it is a problem for Special:Search to be incapable of finding a two-day-old page even when it is given the exact and complete name of the page. Certainly you should be able to add the file in VE, but you also should be able to find the file in Special:Search. Whatamidoing (WMF) (talk) 17:27, 14 August 2013 (UTC)
Note: GreatNurse image is now searchable (manually and via VE). The delay for caching or indexing apparently can be 2 or 3 days. GermanJoe (talk) 09:11, 15 August 2013 (UTC)
The problem can be tested by picking a file not saying "uploaded a new version" at Special:Log/upload. If the file name is placed in quotes, or gives no search hits without quotes like currently File:Misscwymexico.gif, then VE's Insert media box is blank when you enter the name. There isn't even a message indicating a search was performed with no results. The blank box must be very confusing to users. PrimeHunter (talk) 10:52, 15 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
While VE does make adding intra-Wiki links a lot easier, I'm having issues adding links to other websites. I know it's probably just me not doing something obvious but it's not particularly intuitive.Red Fiona (talk) 20:38, 14 August 2013 (UTC)
The user guide says, To link to a web page outside of Wikipedia, the process is the same; just enter the link in the field and it will be added as "external link". :) enjoy, --Elitre (WMF) (talk) 20:45, 14 August 2013 (UTC)
@Redfiona99: Correct. It's true that for Wikipedia articles, plain links are typically references (not good references - good references have a publisher, a title, and published or access date, at minimum, as well as the link itself). But VE is intended to be used to edit all types of pages, and for lots of other types of page, a plain link is just that - not a reference, just a link. So the developers didn't assume that an external link should automatically become a reference.
Cool, I didn't know if it was a thing that was supposed to be working but wasn't, or something that was never supposed to be working. If that makes sense.Red Fiona (talk) 22:56, 14 August 2013 (UTC)
My problem is more suited to the section below that in the help, but that's exactly the sort of thing I meant. It's not obvious that I have to "add reference" and then go to "transclusion" just to add a link.Red Fiona (talk) 22:56, 14 August 2013 (UTC)
@Redfiona99: Sorry, I pointed you to the wrong section - it was the one below, WP:VE/UG#Adding a new reference, as you noted. I've also just changed the wording in that section, to make it clearer that you can put a naked URL into the initial input box - you're not limited to doing that via transclusion/template. Having said that, it is preferable to use a cite template for references, and this does mean (in VE) invoking the transclusion dialog from within the reference dialog, something hardly intuitive. Hopefully VE will be changed to have a better UI/UX; this is clearly a case where the current wikitext editor (with its ref bar) is probably better for novices. -- John Broughton(♫♫)00:52, 15 August 2013 (UTC)
Since the introduction of VisualEditor, I've been trying to use it as much as possible. However, that isn't always possible. One area which has caused the most difficulty is templates. On VisualEditor, when adding a template, you're supposed to see a list of possible parameters - but it appears this only works for a few templates, and for many more it doesn't work.
In any case, the real problem is that when adding a template with VisualEditor, you need to know the names of its parameters. When normally adding a template, that's not the case; you can just put in terms 1, 2 and 3 and let it work without having to worry about the source code. To give an example, I just tried to add {{distinguish}} to an article with VisualEditor, but while I've used that template a lot, I realised I had no idea what the parameters are actually called. I never needed to know them before. The same applies to many of the other {{redirect}}-type templates.
Why can't VisualEditor, rather than requiring the names for the parameters, simply accept 'term 1', 'term 2', 'term 3' and so on? Robofish (talk) 21:07, 14 August 2013 (UTC)
The process for - and progress of - adding parameter names is described at Wikipedia:VisualEditor/TemplateData. The template {{distinguish}} isn't listed; that doesn't prevent it from having TemplateData added to it, but it means that it's not going to occur to uninvolved editors that this template is important.
More generally, WP:VE/UG#Editing templates doesn't describe how to work with a template that lacks TemplateData, but it in fact is possible. Here's how:
1. Select the template, as normal
2. In the "Add parameter box", type "1" [without the quotation marks]
3. Click on the blue-tinted box that appears, below where you just typed. Do not click "Apply changes"
4. Fill in the value for the first parameter. (You can also do this later.)
5 Click on the template name ("Distinguish") to add another parameter. (No, that isn't intuitive.)
6. Repeat steps 2 though 5 as needed, but (of course) don't repeat the parameter number.
7. When done, click "Apply changes" to exit the dialog box.
And speaking as someone who tries to keep WP:VE/UG current, I do not plan to add this information to that guide. We're trying to keep the guide focused on what novice editors need to know. Eventually the tens (hundreds?) of thousands of templates will all have TemplateData, and this will be largely irrelevant. -- John Broughton(♫♫)21:58, 14 August 2013 (UTC)
Thanks for the reply. It's frustrating that all templates apparently have to have their TemplateData added manually, rather than having some kind of automatic conversion. But judging from your explanation, it seems it's already possible to do exactly what I want them to do, I just didn't know how. Robofish (talk) 23:44, 14 August 2013 (UTC)
It could be very slow to get all the TemplateData added. There are about 300,000 templates and the current rate of adding template data is slow 350 done so far (see Wikipedia:VisualEditor/TemplateData/List). We can assume that for a long time to come there will be undocumented templates.
I do not use the VE. Nothing against it (and nothing much for it either), quite simply I am used to Opera and it does not work on it, and I'd point that a major feature not working under IE looks like a rather poor choice. Whatever... I wish you good luck, and I am making a point as to I do not have the faintest idea about how VE works, or not. I have noticed a user inserting what they think is 'references' in a couple of articles, see one diff and the other diff. Newbies will make mistakes, always did, always will, here and everywhere, but... IS tere a chance that the VE is helping to further confuse the editor?
(Note: A huge template, and lots of text to read and write down to make a report for the *visual* editor?! :-) - Nabla (talk) 23:03, 14 August 2013 (UTC)
The reason IE isn't supported yet is simply because it ignores the standards all the other browsers use. This means you can write some code and be pretty certain that it'll work as intended in Firefox, Opera, Chrome, etc. but you then have to rewrite significant portions of it to work in IE. The developers have simply chosen to get it working in the majority of browsers first, and then to convert the working product to IE rather than develop simultaneously.
The difs you cite seem to me to be simply a new user not understanding that other Wikipedia are not suitable as references, VisualEditor can't teach them that and I guess the only thing that VE has done rather than the source editor is put the links inside ref tags. I don't do much work with new users though, so I'm not the best person to speculate. Thryduulf (talk) 08:01, 15 August 2013 (UTC)
Thank you. But I note it does not work on Opera either. So it looks like it is not that it works everywhere except for IE, instead it works only for a handful of browsers. But that was not my main point, the point was about inserting references, and if VE is not misleading new editors in that matter, then fine by me. - Nabla (talk) 09:36, 15 August 2013 (UTC)
Opera 12 and higher is semi-supported: it is not whitelisted, but it is not blacklisted either. You can use it, but it may have more problems than usual. There is a warning given to this effect when you open it. If you do encounter any problems in Opera, then we definitely want to know about them. Whatamidoing (WMF) (talk) 18:01, 15 August 2013 (UTC)
....>>IS tere a chance that the VE is helping to further confuse the editor?<<....>>But that was not my main point, the point was about inserting references, and if VE is not misleading new editors in that matter,<<
Hi there , I am just another experienced user like you (i.e.not from developer team).While I respect and understand your concern.It seems to be more related to user behaviour along with ease of access,and not a bug in itself.
As far as the particular edit diff links you have given and your discussion with the user on his talk page the user is clearlly informing you reason of his behaviour is ....added a number of references.....in order to get it be removed from the deletion list.For the particular case you have noted here, my take,newbie user behaiour is coming simply out of newbie user ignorance + the way en-wiki puts up the pressure on the user to follow various rules;only that earlier newbies may have been qutting the scene more easily under pressure here user is taking his best chance with VE access.
It is for en-wiki supporting experienced people to bring in better measures to create awareness at the right time.And some where else I mentioned en-wiki needs to have more specific edit filters post VE scenario for user support purposes.
May be your observations are still right but to study them en-wiki needs to put in more specific edit filters to see exactly how user behaviour is changing with ease of access and what measures can be introduced.
Hello, I suppose experts will help you. Mean while I tried to exmine and investigate searched user edit and then google on my own.And I hope is not related to FoxLingo- firefox addon issue at user level ? and this one related ?
I think it's both a problem with the browser extensions and VE: VE should be able to prevent that kind of addition from browser extensions, but I don't know how. I thought VE was managing all the editions by javascript, not relying on the browser (handling the text cursor, ...), so I do hope it could be able to handle that kind of modifications by browser extensions. --NicoV(Talk on frwiki)13:20, 15 August 2013 (UTC)
double-clicking on a Visual Editor word (e.g. to select the word) is equivalent to an attempt to close the page, i.e. opens a pop-up window asking if you want to leave or return to the page
I was not able to reproduce this. Can other people with similar configs try? Can you also share the title of the page? (I have seen weird behaviors on specific pages before.) --Elitre (WMF) (talk) 08:34, 9 August 2013 (UTC)
I suspect this (and the previous issue) might have to do with Mozilla not being properly/fully supported yet. I hope to have more details about browser compatibility when devs are back from Wikimania. --Elitre (WMF) (talk) 10:16, 9 August 2013 (UTC)
New References Do Not Populate Until Changes Are Saved
One thing I noticed while using the beta editor is that, when I inserted a new reference, there was nothing in the reference section to indicate that a new reference had been edited. Instead, it looks like the references are misaligned or, towards the end, use a citation number that doesn't exist. Jackeys (talk) 04:40, 15 August 2013 (UTC)
It could be that this is the same as T53689, but I'm not sure so I'll see if the others following this page agree before copying your comments there. Thryduulf (talk) 07:52, 15 August 2013 (UTC)
This is quite a speed bump to editing, but not something which completely breaks the editing process. There are a number of things like this that inadvertently decrease the information-content per edit session. This could be a good thing or a bad thing depending upon your point of view. --User:Ceyockey (talk to me) 02:30, 16 August 2013 (UTC)
Whatamidoing (WMF), that is indeed the change that I'm referring to. Thryduulf, it sounds like the issue I'm referring to is related, but it's not entirely the same. It sounds like adding a new reference doesn't update the existing references list, which manifests itself in the reference section not being updated, and the newly added reference not being available for insertion into the article again until the article is saved and edited again. It seems to me that these are two symptoms of the same issue. Jackeys (talk) 14:50, 16 August 2013 (UTC)
This is a minor bug but an important one for accessibility and automation: the tab order in the "Save" dialog in the Visual Editor is rather screwy:
On Chrome Version 28.0.1500.95 m on Windows 7 x64: It starts in the edit summary field, goes to the "minor edit" link (not the checkbox), then the Save page button, then the Review your changes button (moving right to left), then the three links in the small text at the bottom, then the address bar, then the Search box, then the minor edit checkbox, then the "Interactions" menu drop down on the left sidebar (???), then the Watch this page checkbox. If I use SHIFT+TAB it goes to Edit summary link, then jumps straight to the Mediawiki logo way in the bottom right.
On Firefox 22.0 and 23.0 on Windows 7 x64: It starts in the edit summary field, goes to the "minor edit" link (not the checkbox), then the Save page button, then thereafter neither TAB nor SHIFT+TAB do anything (focus is stuck - this is a serious problem as it may require reloading the page and losing edits). SHIFT+TAB is same as in Chrome.
Conventionally, tab order is supposed to go in a logical reading order: left-to-right, top-to-bottom. My expected order was something like this:
Starts in edit summary field, goes to minor edit checkbox, then minor edit link, then Watch this page checkbox, then Review your changes button, then Save page button, then the three links at the bottom. If I use SHIFT+TAB to tab backwards, I expect to visit the Edit summary link, then (if possible) the arrow to collapse/abort the Save, then the Search box.
As an experienced editor, I considered this new tool a good step forwards in encouraging new people to edit. However, the new editor is actually harder to use than good old wikimarkup. Referencing is infinitely more difficult with the new (and dodgy) templates tool, adding parameters takes far longer than simply using tools like proveit. To make matters worse, after I had finished editing and clicked 'save page' the visual editor hanged and I lost all of my work. Jr8825 • Talk12:45, 16 August 2013 (UTC)
I'm sorry you lost all of your work. VisualEditor doesn't completely hang often, but it frequently takes an impossibly long time to finish saving, easily requiring several minutes on some complex pages.
I agree with you that something like Prove IT or sort of autofill system for refs would be desirable. ProveIt is not part of the MediaWiki software, but its own developers are free to update their code to work with VisualEditor, and I believe that everyone would welcome this. Regardless of what ProveIt's devs choose to do, the WMF's devs are also working on both speed and reference work for VisualEditor. These are both significant priorities. Whatamidoing (WMF) (talk) 16:49, 16 August 2013 (UTC)
Here's another observation from further using VE: it's inconvenient that it doesn't have cut/copy and paste functions. I can copy and paste text within my browser, but it doesn't seem to be possible to copy-paste templates and other elements. (In the old editor, this isn't a problem, as you can just copy the source text.) That means there's no way to move a template to another place in an article, or duplicate it, short of recreating the whole thing. I'm not missing something here, am I? Robofish (talk) 22:20, 16 August 2013 (UTC)
Well, you may be missing one small thing: It is possible to copy a template if you select surrounding text with it, such as text text. However, this still doesn't allow you to paste it into other articles, which, as you point out, would be a very useful feature. --Cryptic C62 · Talk22:41, 16 August 2013 (UTC)
Yes. There are both bugs to fix and enhancements needed to copy and paste within/from/to VE. Almost every issue has it's own bug number, but T35105 tracks them and T51496 is the one specific to copying templates and references requiring you to copy a non-space character either side of it. Thryduulf (talk) 23:33, 16 August 2013 (UTC)
Will there be a way to switch to Edit Source after putting in some changes with the VisualEditor? For example, I fix up some prose with VE, and then I want to make a detailed cite web but don't want to navigate the reference button. -AngusWOOF (talk) 01:21, 17 August 2013 (UTC)
Hopefully. This is an often requested feature, tracked as T49779 but marked as a low-priority enhancement so don't hold your breath. Sorry. Thryduulf (talk) 01:27, 17 August 2013 (UTC)
When the priority was set, it seems that "low" was chosen because compared to the other major problems (like "can't add refs" and "can't add images"), it was certainly less urgent. I've asked them to reconsider. I wouldn't expect much very soon (major upgrade arriving here on Tuesday), but I'll let you know if we get a positive response. Whatamidoing (WMF) (talk) 00:46, 18 August 2013 (UTC)
As much as I prefer using source editor in almost every circumstance, I actually think that the priority on this should be low. With a finite number of dev team each week, higher priority should be reserved for features that make VE more readily accessible to newer users. While this feature would be very cool, I imagine it would be a very complicated endeavor without much positive impact on new users. --Cryptic C62 · Talk05:17, 18 August 2013 (UTC)
Error in references
I inserted a reference in this NS1 Antigen Article. It was in the middle of the article, probably the second last reference, but the visual editor created a new reference at the beginning of the list. Now the numbers of the reference and the text do not add up. Medschneverends (talk) 03:48, 17 August 2013 (UTC)
I might be wrong, but, at this point in time, I don't think that you can add <br> tags. You could, however, do this:
One
Some commentary.
Two
Some other commentary!
Three
Four
What's currently possible might even be the technically correct thing to do (according to the HTML standards), since the commentary is not intended to be part of the numbered HTML list item. Whatamidoing (WMF) (talk) 00:56, 18 August 2013 (UTC)
<nowiki/> works by itself and isn't an ending tag without a start. See WP:NOWIKI. VE placed the space in a silly place inside the wikilink instead of outside, and then <nowiki/> or something else was needed to not make "module" part of the link. Compare GPS module and GPS module. PrimeHunter (talk) 22:39, 18 August 2013 (UTC)
Dropdown menu formatting, backspace/delete
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Is this expected behaviour? Take two lines. Line 1 is blank (or has text, doesn't matter). Line 2 has text. Put cursor on line 1, and select some formatting according to the dropdown box. Select all the text on line 2, give it a different formatting according to the drop down box. Go to beginning of line 2 and press backspace, or to (end of) line 1 and press delete. The second line merges with the first line and takes on whatever formatting the first line had. Pressing enter to break the lines doesn't return the formatting. Doesn't happen with bold/italic. --Atethnekos(Discussion, Contributions)16:15, 17 August 2013 (UTC)
If the formatting is paragraph-based (section headings, line items, etc.) rather than character-based (bold, italic, etc.), then basically, yes: when you take two paragraphs and make them into one paragraph, it is not possible for the resulting single paragraph to simultaneously have two different paragraph-based styles. This is what happens in word processing documents, and it's also what happens in the wikitext editor. Whatamidoing (WMF) (talk) 00:51, 18 August 2013 (UTC)
It makes sense; the one case seems really weird though: You have a section heading, and above it a blank line that is "paragraph" formatting, when you backspace from the start of the heading (or delete from the blank line), the section heading merges with the blank line and takes the "paragraph" formatting. I would expect it just to remove the blank line and move the section heading up one line. --Atethnekos(Discussion, Contributions)18:07, 18 August 2013 (UTC)
I agree. It's fine if you're talking about, oh, bulleted lists and paragraphs, but it doesn't make sense in that particular situation. I hope they will create some special handling for that. Whatamidoing (WMF) (talk) 16:52, 19 August 2013 (UTC)
Edit summary
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Hi, I have been using VE a bit and am chagrined whenever I enter an edit summary and hit "enter", expecting my page to be saved, and only get a new line in the edit summary box. It would be awesome if hitting enter in the edit summary box saved the page. That's all! Keilana|Parlez ici06:03, 19 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
I'm finding that I cannot re-use a reference in VE if I have just added it in the editor. I first must save an edit with the new source, then re-open the editor to re-use the reference. For some reason, the references do not generate until I've actually saved an edit, so cannot be re-used until the first instance is saved. So if I am using multiple quotes from a single source, I must either cite only the first quote until I save my work and re-open the editor, thus leaving the other quotes temporarily unattributed, which I don't like doing, or else I must only transcribe the first quote, cite it and save, then re-open the editor to add the other quotes, which is quite time consuming.--¿3family6contribs16:01, 19 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
In the wikitext editor, you drag-n-drop text and code from one part of an article to another. VE (still?) doesn't support this. This might seem trivial, but I've found that drag-n-drop is a nice enough convenience to be significant.--¿3family6contribs16:08, 19 August 2013 (UTC)
According to http://wiki.riteme.site/w/index.php?title=Wikipedia_talk%3AFlow&diff=569260097&oldid=569182992, the <math> tag is supported in Parsoid, but not in VE, due to a lack of a hook. Since LaTeX is so ubiquitous in math markup, a trivial hook that just added the option to add math from the interface (with the instructions stating it uses LaTeX markup), and the ability to edit preexisting math would likely solve a lot of issues. A fully visual version probably isn't as useful in the short term when the code is so standardised.
Another easy support that could be added would be a simple, cut-and-paste-in-the-code LilyPond hook. There are many programs that format LilyPond, so merely pasting it in isn't so bad of preliminary functionality, particularly if you link to http://lilypond.org/web/about/faq in the pop-up box. Adam Cuerden(talk)18:44, 19 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
I experimented with the Beta editor to insert a reference to a source for something I had just added to the Cradley Heath Baptist Church article. I used what I thought was a Preview function which came up as Compare Changes. When I saved the edit, the reference came up in the text, complete with the ref and /ref tags. going to the old editor to find out what had happened, I found nowiki tags had been added. Removing these cured the problem. Perhaps I should check the User Guide to find out what I should have done. Robert of Ramsor (talk) 22:06, 19 August 2013 (UTC)
VisualEditor doesn't have a lot of legacy support at the moment. I'm rather hoping more gets added, but the problem is that they have to balance legacy support with not breaking everything if someone decides to do something stupid, so there's probably a limit. Adam Cuerden(talk)23:39, 19 August 2013 (UTC)
Math text that doesn't parse when in VE
If you edit this revision of radiocarbon dating with VE, and scroll down to the section on accelerator mass spectrometry, you'll see a math parse error, although the math parses properly when not in VE. I know it can't be edited, so it's harmless, but it's ugly and might indicate other parsing errors. Mike Christie (talk - contribs - library) 11:05, 18 August 2013 (UTC)
Looks like it displays OK when not in VE in Chrome/Win7, but not in IE9/Win7. I don't know if there's anything wrong with the math markup, but it's odd that it should parse it differently in VE than out. Mike Christie (talk - contribs - library) 13:16, 19 August 2013 (UTC)
If we are talking about the red "Failed to parse" messages, I can see them in the diff yet with both FF and Chrome on Win7, so not a VE issue. --Elitre (WMF) (talk) 14:41, 19 August 2013 (UTC)
I see the red error messages at Radiocarbon dating#Accelerator_mass_spectrometry when I'm just reading the page, for both Firefox and Safari. If the code really appears to be correct (ask for more opinions from WT:MATH, maybe?), then we presumably need to file another bug on the wikitext editor and its parser. Ssastry and the rest of the Parsoid team might be interested in knowing about it as a possible edge case for testing, although the problem is clearly independent of VisualEditor and Parsoid. Whatamidoing (WMF) (talk) 17:04, 19 August 2013 (UTC)
Do you have mathJax turned on? It looks like the formula parses fine using MathJax but not with the texvc parser. The problem is mixing UTF8 character with maths. There is a unicode δ character in each formula with causes the formula not to parse correctly. Using \delta instead and it works fine. Other unicode also cause problem notably the proper minus symbol U+2212−MINUS SIGN rather than a simple hyphen U+002D-HYPHEN-MINUS and there also seem to be a problem with a quote character. MathJax is modern enough to handle unicode but texvc is older and stricter.--Salix (talk): 20:53, 19 August 2013 (UTC)
We are getting the default MediaWiki rendering from the API which is currently using texvc. We'd like to render using MathJax instead, but will need changes to core before we can do this. See bug 51698. -- GWicke (talk) 20:06, 20 August 2013 (UTC)
Problem with beta editing
The following discussion is marked as answered. If you have a new comment, place it just below the box.
After using the beta edition and saving changes, site refreshes and gets back to beginning of page, instead of the changed section. Lmfardin (talk) 12:36, 19 August 2013 (UTC)
It has to do with VE's known limit that section editing is not supporting, so you are not actually editing a single section (you probably don't realize it since the page still scrolls to the section you want!), and therefore you see the whole page when done. Do we want to ask and see if it can/should still be done (I am referring to the part of getting back at the single section, not to this)? --Elitre (WMF) (talk) 16:12, 19 August 2013 (UTC)
@Elitre (WMF): - If someone edits uses VE, and starts the editing session in a particular section of a page - something that gets noted in the edit summary - then it seems logical that after the edit is saved, what should be displayed is the page, in read/view mode, at that section, not at the top of the page. This is how the wikitext editor works: edit a section, and when you save your edit, you return to viewing that section. This is what Facebook does, for example, if you click on an image, and then close that image. This is pretty much what any website does when a reader returns focus to a main page.
I know that this is how the classic editor works, but since VE does not actually allow real section editing and you still have to load the whole page (unlike the classic editor), it seemed a logical consequence to me that once you save you go back at the beginning of the page - probably not just to me, since I am reporting this for the first time, it seems :) Now here, thank you! --Elitre (WMF) (talk) 10:48, 20 August 2013 (UTC)
VE can't parse a table and as a result damaged it when the article was saved
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Status
New:
Description
I did a minor change to to the text of a page. VE did that change but also broke a wikitable in the section following the one I edited. Related to this is that while in VE the table was not displayed. In its place I saw "{| class="wikitable"" followed by the table contents though not formatted as a table implying this is an issue with VE parsing the original wikitext.
To duplicate:
Run VE on this page. When looking at the diff, I intended to change "Eclipse" to "Ecxxxlipse". The remaining stuff that was changed was a VE generated side-affect.
Currently when you click on a template with the "VTE" (view, talk page, edit) links, Visual Editor gives you the option of adding parameters to the transclusion of the template. Most of the templates with the "VTE" links are navigational boxes or other transcluded items without parameters, but as the VTE links suggest, we want people to easily view the template page itself. Maybe if someone clicks on a template with VTE links in Visual Editor, rather than being given the regular option to add parameters they should instead be given a dialogue box saying something along the lines of "This is a template that appears on many pages. Would you like to open this template's page in a new tab?". —Arctic Gnome (talk • contribs) 13:45, 20 August 2013 (UTC)
Ok, but there is a point here I had not thought about, we should make it far more obvious now that 1) changes through VE will only affect the way that specific template behaves on that page only 2) which parameters are then allowed. This was not an issue before since users knew they had to find their way to the template page to change its global aspect; they are now apparently given the option to edit single instances of such templates and might not realize these edits will not be recorded on the template page instead. Ping @Arctic Gnome and Whatamidoing (WMF) to see if I am missing something here. --Elitre (WMF) (talk) 13:39, 21 August 2013 (UTC)
Most people probably didn't know that it was possible for them to change navboxes or other templates, especially if there is no "VTE" label. If people wanted to do this, we could suggest a "click here to open the original template in another window" button. I wouldn't be surprised is "ease of editing" equated to "ease of screwing up", though, and was not an especially popular option with the template editors (the people who are most likely going to have to clean up mistakes made by inexperienced people—or even experienced ones. I've screwed up in templates before). Whatamidoing (WMF) (talk) 21:31, 21 August 2013 (UTC)
Carol Semple Thompson
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Hi Redrose64, I don't see anything weird with those links, just common behaviour trigged by unexperienced users. In the first case, the user pasted the URL of the page he wanted to link to, instead of typing its title (I think VE shouldn't allow this, but I am not 100% positive this was already requested - I wanted to ask it myself). In the second and third case, that's the expected outcome when the user ignores the "wikitext warning" and saves, instead of using the correct tool to create the links. Or am I missing something? Thanks. --Elitre (WMF) (talk) 09:02, 21 August 2013 (UTC) PS - this is what I was talking about in the brackets.
It's T44986 for the external link to the English Wikipedia. You might not want the conversion to be automatic, because that would preclude using it as an example of how to make an external link and might cause complications if you're referencing a particular version (although you should be able to identify that from the structure of the URL). Whatamidoing (WMF) (talk) 21:39, 21 August 2013 (UTC)
Well, it turns out that this is not necessarily user error. They've just issued an emergency patch for external links being added when you wanted an internal one. If you see any more of these (starting as of about two hours ago), please post the diffs. Whatamidoing (WMF) (talk) 02:20, 22 August 2013 (UTC)
VE appears in IE10, but only on one article
I just got a Edit beta tab on The Adventure of the Reigate Squire, even though I'm in IE 10. What's weirder is that this is the only page where I've seen a VE tab. Also, I can't make any edits with it: I changed a few words in one sentence and added an edit summary, but the thing's just hanging there. I got a message of Warning: Your edit may have been corrupted – please review before saving. However, I've been unable to find anything corrupt, even though I reviewed everything that I'd done. Nothing of WP:EF came up, either. 2001:18E8:2:1020:202A:8DD6:6403:B77 (talk) 16:25, 21 August 2013 (UTC)
It's weird because as far as we know IE is still on the "blacklist". So until that does not change, should you encounter the VE tab again (I did not get it on my IE on that article), remember it is not going to work yet, as you reported. If you're interested you might add yourself to the CC list for this bug. --Elitre (WMF) (talk) 16:58, 21 August 2013 (UTC)
That's why I said "even though I'm in IE 10", because I know that it's supposed to be disabled. But why do I get the tab when the software won't let me use it, and why does the tab appear just on one page? 2001:18E8:2:1020:202A:8DD6:6403:B77 (talk) 17:26, 21 August 2013 (UTC)
Why do you get the tab in the first place, while I don't? I have no idea :) That's why I had added your feedback to that ticket. Thanks! --Elitre (WMF) (talk) 17:28, 21 August 2013 (UTC)
I wonder if its something to do with your user agent. If its been modified in some way Wikipedia won't be able to tell which browser you are using and might be tricked into trying to use VE. As VE has not been tested to IE10 you will get a half working system. You can check you user agent at [12] its the first line in the results.--Salix (talk): 18:00, 21 August 2013 (UTC)
If I start with a blank page, click a list icon, type in "France", press enter; I don't see any way to get my cursor to a position before the list so that I can enter data there. --Atethnekos(Discussion, Contributions)22:34, 21 August 2013 (UTC)
hey folks -- Last night I created a new article with multiple references, and when I saved the page many of the references disappeared and some I think had jumped around. (I didn't save-as-I-went -- I wrote the whole thing and saved once, at the end.) I can't describe exactly what happened, but here's a diff: the latest revision is roughly what I was aiming to do, and the earlier revision is what I actually achieved. (Ignore the missing reflist: I just hadn't gotten around to figuring out how to add it in VE yet, so I did it afterwards in wiki syntax.)
So, in my initial VE save, it looks like references #5, 6 & 7 disappeared as did #14 and 15. (Numbers taken from the latest revision.) This suggests to me there's a problem with VE saving multiple adjacent references -- when there are multiples adjacent, it seems to save only the first. I think also some references jumped around, but I'm not 100% sure about that.
Also and separately: today I tried and failed to delete the empty spaces between multiple adjacent references (between #13 and 14 and #14 and 15). Post-save, I got a success message but the spaces remain, and there's no record of the edit.
I haven't checked Bugzilla for either of these -- apologies if they're duplicates. (I'm a bit sick and therefore lazy.) I'm using Chrome 28.0.1500.45 on Ubuntu 12.10. Thanks Sue Gardner (talk) 22:47, 21 August 2013 (UTC)
You may have two bugs here. Did you by any chance do some cut-and-paste rearranging that involved the "[3]" sentence about "...rooted in the assumption that, in general, a man is likelier to be knowledgeable than a woman"? There's a known bug about copying and pasting.
I'm pretty sure that the other one, T54228 about multiple refs in a row, was supposed to be fixed in the previous (not the most recent) release. We may need to re-open that.
If you haven't discovered it yet, the <references /> item is added by clicking the icon that looks like a row of three books: .
This page is for feedback on VisualEditor, our new user interface. For feedback on a specific page, please leave a comment on the article's talk page. --Cryptic C62 · Talk01:45, 22 August 2013 (UTC)
It's working for me. The only advice I could suggest would be of the "restart your computer during a full moon, while chanting the name of your favorite open-source product" variety, which is unlikely to be helpful. Perhaps someone more familiar with TemplateData will have a more useful idea. Whatamidoing (WMF) (talk) 18:29, 13 August 2013 (UTC)
Since the template is working for other people, TD is just fine, I'll correct myself that changing browser might not be the solution if one does not purge its cache as well :) --Elitre (WMF) (talk) 08:33, 14 August 2013 (UTC)
Whaddya know, its even more complicated! I tried on another pc, logged in to WP, and still numbered accounts. Then i tried chrome, on same pc, not logged in and voila! parameter names! Then I logged in, and... numbered parameters. I tried it then on a virtual box, windows + firefox, logged out: named variables, logged in:... numbered variables...
Do you get the same for other templates like {{lang}} or {{Infobox single}}? Is it only for new templates or if you edit existing ones? This might help test if its some weird caching problem or something else. Also if you have some developer tools for your browser check to see if there are any javascript bugs. You can get odd behaviour if a bit of javascript crashes.--Salix (talk): 18:08, 14 August 2013 (UTC)
On chrome you can see the javascript console by going to the chrome menu to the right of address bar, selecting tools, then Javascript Console.--Salix (talk): 18:17, 14 August 2013 (UTC)
Yep, same deal with {{lang}}. I dont think i have any weird preferences, because i generally stay away from those. The chrome javascript console in chrome doesnt report any errors. Im happy to give my password to any one with a wmf account (or anyone people here judge genuine) through wikimail, contacting me on my talk page, to try out my account. -- Stratoprutser (talk) 09:21, 15 August 2013 (UTC)
If you are located near any of the Future meetups or a local chapter then you could arrange to meet someone there who could help you. You do not need to reveal your real-world location, or meet any other person in real life if you do not want to. Thryduulf (talk) 10:13, 15 August 2013 (UTC)
ok ok, you convinved me, so:
mw-prefsection-gadgets
"Ask a question" feature for the Wikimedia Foundation's "Teahouse" project
Reference Tooltips: Roll over any inline citation to see reference information, instead of having to jump away from the article text
Form for filing disputes at the dispute resolution noticeboard
CharInsert, adds a toolbar under the edit window for quickly inserting wiki markup and special characters
Add a "Sandbox" link to the personal toolbar area.
mw-prefsection-editing;
Enable section editing via [edit] links
Warn me when I leave an edit page with unsaved changes
Show edit toolbar (requires JavaScript)
Enable enhanced editing toolbar
Enable wizards for inserting links, tables as well as the search and replace function
Show preview before edit box
Temporarily disable VisualEditor while it is in beta (no kidding, this is of course unchecked :p )
I'm not ready just yet to meet people who are willing to meet people and talk about wikipedia just yet, sorry, but thanks for the invite :) -- Stratoprutser (talk) 11:08, 15 August 2013 (UTC)
Well I have all those gadgets, plus a couple more, enabled. I don't have the warn before leaving with unsaved changes, enhanced editing toolbar or wizards for links ticked, I do have the others. I don't have time to test right now, but nothing in that lot jumps out at me as a likely cause :/ Thryduulf (talk) 11:26, 15 August 2013 (UTC)
Did I mention that I'm working now on another computer in another office, but in the same town (provider) and the issue is still there, also on this Windows box (only ie8 the ve is disabled)... -- Stratoprutser (talk) 12:19, 15 August 2013 (UTC)
Your Wikipedia settings are independent of the browser or computer you use, so that is consistent with it being some setting on your account that is the issue. Thryduulf (talk) 16:03, 15 August 2013 (UTC)
My real account has these, plus more, except that it does not have these two:
Warn me when I leave an edit page with unsaved changes
Enable enhanced editing toolbar
However, my staff account has both of these. Since the problem follows Stratoprutser from computer to computer, it must be something in the account, but I am not at all certain what that might be.
There's supposed to be a big update soonish (three hours from now, at the earliest?). Maybe this will be one of those problems that just magically goes away. Whatamidoing (WMF) (talk) 17:53, 15 August 2013 (UTC)
Don't worry, User:Stratoprutser, we are not giving up on you. Just to make sure we give correct info to other people we might involve, can you please provide the version number of the browsers involved? (Who knows...) --Elitre (WMF) (talk) 13:16, 19 August 2013 (UTC)
I'm sorry, but the update hasn't happened here yet. It's been put off until tomorrow (it's already up at Mediawiki, but the lang templates don't seem to exist there, so I don't think we could usefully test this there). Whatamidoing (WMF) (talk) 16:46, 19 August 2013 (UTC)
Ah sorry, yeah I just checked quickly and a paramterer appeared miraculously. Didnt do an inter browser check, but guess itll be alright. -- Stratoprutser (talk) 14:42, 28 August 2013 (UTC)
VE breaks tables
The following discussion is marked as answered. If you have a new comment, place it just below the box.
VE breaks tables by inserting "Number =" (e.g. "1=", "2=") text into cells. I'm not super-familiar with the ins and outs of table display, but these numbers seem to control ordering of the rows, so that insertion/deletion of rows is overriden by these small text artifacts.
For articles with the problem, insert {{subst:disable VE top}} as the first line and {{disable VE bottom}} as the last line. That will prevent editors from using Visual Editor on the article. Give me a list when you are done, and I will insert appropriate edit notices.—Kww(talk) 17:14, 18 August 2013 (UTC)
I'll take a look at the specific issue ASAP, I was just wondering, Kww, is there anything I am doing wrong with the templates you suggest? Because after saving a page with them I am still able to edit templates and I can also add text at the top of the page, so, unless there's an editnotice, I'd be just confused as to why VE does not properly handle that page. And report the whole thing as a bug of course :p (but then again, if there is an editnotice, shouldn't that warn enough against using VE on that page?) --Elitre (WMF) (talk) 15:25, 19 August 2013 (UTC)
Elitre, it's the problem with not having an "official" turnoff. VE has changed. Originally, it didn't allow you to select anything at all. Now it simply prevents you from selecting any text, but apparently still allows you to edit templates. The edit notice and not being able to select text seems empirically sufficient, but yes, it would be much better if we had an offically supported way to tell VE to stay away from a particular article.—Kww(talk) 15:39, 19 August 2013 (UTC)
I have seen unsupported gadgets or scripts before, related to VE. In those cases, though, these workarounds, well, worked. I am just personally not sure why we in this case should suggest a remedy which seems worse than the disease - that's why I asked whether I was misusing it :) Again, just my 2c here, I think the editnotices should be enough - and thanks for putting them up BTW. --Elitre (WMF) (talk) 15:52, 19 August 2013 (UTC)
This is T54824 for which I already have a patch in progress. Thanks for the report here. It clarified that this was a more serious bug than we thought. Ssastry (talk) 18:35, 19 August 2013 (UTC)
Should this fix address tables that were affected before, or on,y future edits using the visual editor? See this old version of Logan International Airport. Note that many lines, starting after Delta Connection operated by Chatauqua and including JetBlue, do not (and still do not) display in the table.
I think that the sequence that leads to the problem is 1) someone edits with the visual editor, introducing the numbered fields in the table. 2) Someone removes or moves a row editing the source, which makes the numbered rows out of order. The table doesn't display correctly when there are non-contiguous table element indices. —Alex (ASHill | talk | contribs) 20:58, 21 August 2013 (UTC)
Thanks Elitre for the ping. ASHill, this fix applies only to future edits using the VE. The older bad edits with VE either have to be manually fixed or reverted. I am happy to help with the cleanup of bad edits on that page if you need any assistance with it. Ssastry (talk) 14:41, 22 August 2013 (UTC)
...but that text is not on my screen. I'm a new user: you may know where the text is because you may have been looking, but I just spotted an issue in something I was reading and now... 37.188.82.157 (talk) 23:22, 18 August 2013 (UTC)
Not sure I understand what you mean: by hitting Edit source, like you did in order to write here, you'd get... the wiki markup. With VisualEditor instead, in articles and user pages, you get to edit the content pretty much the way you see it, as if it was a word processor. So, spotting and fixing issues now should be really, really easier. If something specific did not work for you, please share it with us, thanks. --Elitre (WMF) (talk) 15:44, 19 August 2013 (UTC)
'Edit source' does not appear if you are using Internet Explorer or several less common, older web browsers. It normally appears only if you have the option of using VisualEditor. Whatamidoing (WMF) (talk) 17:14, 19 August 2013 (UTC)
Erg. Can we get around to changing that name before people get used to it? It's kind of against the goals of making things easy for users to understand, and if it becomes fossilised, we'd get stuck with a situation where a very unhelpful and off-putting bit of naming will get presented to our users for all time, regardless of whether they can use VE or not. Adam Cuerden(talk)18:46, 19 August 2013 (UTC)
Actually, from a UX point of view, it's far better for the same action (editing the wikitext) to have the same label regardless of other factors (browser, VE opt-out status, namespace, etc). That way we can tell a new user to click "edit source" (or whatever the label is) and be certain they have an "edit source" option to click without needing to know the state of other things. Thryduulf (talk) 14:35, 22 August 2013 (UTC)
"Edit source" - prerequisite to a !vote
While I don't know how widespread it is, I think there's quite a number of people who dislike the name "Edit source", primarily because "source", when applied to websites, has a very different definition (raw html, generally). Since the whole point of VisualEditor is to improve the user interface, having a misleading name on one part of the interface is a very bad idea, unless it's absolutely necessary.
So, what I'd suggest we do is to make a shortlist of the possibilities, then we can put it to a !vote. I've listed a few below.
"Edit wikitext": "Wikitext" is precisely defined, and, while people may not know what it means, at least it doesn't mislead.
"Edit wikicode": Variation of the above.
Edit (traditional): A possibility, but perhaps a little pompous.
Edit (legacy): I suspect calling Wikitext "legacy" is a good way to call out the pitchfork brigade. Maybe not.
Edit text: This is the one used by MoinMoin, so it has some standardization, but MoinMoin pairs it with "Edit GUI". It probably wouldn't work unless VE's label was changed to something like that.
Edit (text mode) - This might deal with the above issue. "text mode" is, at least, somewhat comprehensible to the uninitiated.
suggested by NicoV: "Edit" for wikitext, "Visual edit" for VE. - This may be a better idea in the short term than the long term: If VE reaches its potential as a really good editor for new users, it should probably be presented as the default.
Not a big fan of 3, 4 (there's no point in telling new users that wikitext is traditional or legacy) and 6 (bof). Rather 5 among them, but why not keeping "Edit" and "Visual Editbeta": in total, it's no more characters than other proposal, and has the advantage of keeping the long known "Edit". --NicoV(Talk on frwiki)22:01, 19 August 2013 (UTC)
Do we really need/want to use this page for such a question? I had to check twice I was not on some RfC talk - of course, after some polling then the results can be added to a bug, as happened before :) --Elitre (WMF) (talk) 22:10, 19 August 2013 (UTC)
It seems a good place to talk through ideas, and to try and get it down to a small number of good ones. When we're ready, THEN we need a full RFC, but some pre-planning makes for a much better RfC. Adam Cuerden(talk)22:14, 19 August 2013 (UTC)
I'll second what NicoV wrote. Use "Edit" and "Visual Edit" (dropping the "beta"). Note that if you can't edit a page it'll still say "View Source." --Marc Kupper|talk23:31, 19 August 2013 (UTC)
"Classic edit" (or "Edit (classic)") has been suggested for wikitext. VisualEditor is a rich-text editor, so "Edit (rich text)" is a possibility.
I'm definitely not the person to provide any definitive answer, but it is possible that "Visual edit" would encounter trademark-related problems. "VisualEditor" is trademarkable (I don't know if they plan to register it or use it that way, only that it's possible to do so, if they chose to), and "Visual edit" might be the sort of thing that gets rejected for being confusable with the trademark. If you think that this option is something you'd like to pursue, then let me know, and I'll see if I can figure out who is in charge of trademarks to ask about whether that option might be a problem. Whatamidoing (WMF) (talk) 18:08, 20 August 2013 (UTC)
Three quick points:
The labels must be a verb or action call, ideally with the verb as the first word not a later one, to fit in with the rest of MediaWiki (and the Web).
The labels need to be understandable to people who aren't native English speakers, and translate well into other languages, which precludes certain terms.
The label for the wikitext editor ("edit source") is based on that for protected pages ("view source") - if we're changing one, we should change both.
Not sure if these points mean that we should consider some additional options.
I think that VE should get the "Edit" tab. For the old editor, I don't mind "Edit source". I guess it somewhat implies raw HTML, but I think anyone experienced enough to want the more complicated editor will figure out what's going on, and for newer editors the word "source" might give them a better understanding of what the tab does. If we changed it, my preference would be "Edit wikicode" because I think that gives the same impression to newcomers as "Edit source". —Arctic Gnome (talk • contribs) 05:03, 21 August 2013 (UTC)
I suspect that's the long-term direction. For example, Microsoft SharePoint's wiki uses "Edit" which opens a rich text (visual) editor. The editor's tooolbar has an icon for "Edit HTML Source" which pops up a box containing the raw wikicode. When you save the wikicode their visual editor re-parses and display it in visual-edit mode. Microsoft "wikicode" is HTML plus "[[pagename]]" and "[[pagename|displaytext]]" for inter-page links. When in their "visual editor" you see and edit the "[[...]]" stuff directly. I assume MediaWiki will move in the same direction where "Edit" will open the VE and from within that there will be a way to edit the underlying wikicode. --Marc Kupper|talk17:41, 21 August 2013 (UTC)
I think that "classic", "traditional" and "legacy" (and similar terms) should be avoided as it requires knowledge of the history of the interface, that while likely common at this point will become increasingly less so. I don't think that either editor should get a plain "edit" label if the other is descriptive of its method (e.g. "edit wikitext" or "edit visual"), as the alternative cannot be inferred and so doesn't help people make a useful choice. Combining "edit" (for VE) and something like "edit (advanced)" (for wikitext) is fine though as "basic", "standard" or "easy" can be inferred from "advanced". i.e. a plain "edit" label should only be used if the word used to differentiate the other editor has a common antonym that doesn't mislead. Thryduulf (talk) 14:53, 22 August 2013 (UTC)
I like "Edit (advanced)" better than "legacy". I'm not sure that it coordinates well with "View source", though. "View (advanced)" doesn't really make much sense. WhatamIdoing (talk) 17:33, 22 August 2013 (UTC)
Custom labels
If people want to customise the interface the following javascript changes the labels
jQuery(document).ready(function($){// Paste snippet here// Paste as many as you like, only one "jQuery document ready" wrapper is needed!$('li#ca-edit span a').html('WT edit');// changes tabs at top$('li#ca-ve-edit span a').html('VE edit');$('.mw-editsection:nth-child(2) a').html('WT edit');// changes section links$('.mw-editsection-visualeditor').html('VE edit');});
The fix above was for the vector skin thing are slightly different for monobook. Try this in Special:MyPage/monobook.js
jQuery(document).ready(function($){// Paste jQuery snippet heres$('li#ca-edit a').html('Edit');// change label for wikitext edit tab$('li#ca-ve-edit a').html('VE edit');// change label for visualEditor edit tab$('.mw-editsection:nth-child(2) a').html('Edit');// change label for wikitext section edits links$('.mw-editsection-visualeditor').html('VE edit');// change label for visualEditor section edit links$('.mw-editsection-bracket').css('display','none');// Don't display [ ] square brackets for section edits // $('.mw-editsection-divider').css('display','none'); // Don't display the | divider for section edits (commented out)$('h1#firstHeading .mw-editsection-visualeditor').css('display','none');// Don't display the section 0 VE edit link which is broken$('h1#firstHeading .mw-editsection-divider').css('display','none');// Don't display the divider for section zero});
I've also added a couple of other changes to not display the [ ] in section edit links. Comment out as needed. i think this should also work for vector.--Salix (talk): 05:34, 22 August 2013 (UTC)
Thank you Salix. I was and am using User:Marc Kupper/vector.js. My reference to monobook above was a typo. The last line for h1#firstHeading .mw-editsection-divider did the trick in that it removed the beta that started showing up. That, however, really confuses me. I can't see how switching "h1#firstHeading .mw-editsection-divider" to display:none turned off the <span class="ve-tabmessage-appendix">beta</span> and that it was able to do so for the tabs at the top, the first section, and all following sections. --Marc Kupper|talk16:29, 22 August 2013 (UTC)
Hi there, although I am not sure exactly to which bug this belongs, there's a bunch of them (about pawns) still open, so I am not surprised, and I also think this is one of the main reasons why the label potential VisualEditor bugs exists and is applied to edits. Thanks, --Elitre (WMF) (talk) 13:57, 20 August 2013 (UTC)
It's most likely due to the presence of an unnecessary/improper extra "line" on the table. That table ended with
|-
|}
and it should have ended with just the |} part. I wonder if there's a way to find all instances of such malformatted tables and repair them. A bot, maybe? Whatamidoing (WMF) (talk) 18:25, 20 August 2013 (UTC)
Well, generally speaking, if a user adds wrong code on some articles we can't really expect someone to use VE there sooner or later so that the code gets fixed. We should 1) make sure we write tables correctly so that they also work with whatever editor :) 2) hope that VE will be able to fix these things anyway - probably not now though, I think people might want it not to "break" code, in the meantime! --Elitre (WMF) (talk) 12:00, 21 August 2013 (UTC)
Well, yes, but the example given, while "wrong", is harmless without VE. If VE fixes, it will never be a problem for VE; if a bot fixes it, it'll only not be a problem if the bot spotted it in time. Adam Cuerden(talk)21:09, 21 August 2013 (UTC)
FWIW, I had not known a trailing |- was "wrong" and have been using that when I create tables as visually, I like the separation between the last row and the |}. --Marc Kupper|talk02:17, 22 August 2013 (UTC)
Like Marc, I didn't know a trailing |- was "wrong", and so as long as people are able to create tables by handrolling the syntax it is something that will continue to appear in new edits. To my mind this means it is something that VE should expect to encounter and be agnostic about. Thryduulf (talk) 14:59, 22 August 2013 (UTC)
If I want to make a link to e.g. target, why does I have to find it on the list first? Target coperation is the first on the drop-down-list, and if I press escape (the list disaperes) and only "target" in the "link-box", but the actual links I get is the first entry on the list.
Why are the red links blue? Its misleading - maybe all the links should be colored another color?
When open the link-box at the bottom of the page, I cant see the list (without scrolling - using the mouse) - Christian75 (talk) 09:39, 20 August 2013 (UTC)
The first two are known bugs (can't find the link for the first one now, sorry, while the second should be this. For the last one, the "link-box" is prompted exactly under the word, if this does not happen for you, please list OS/skin/browser so that we can check better, thanks. --Elitre (WMF) (talk) 15:10, 20 August 2013 (UTC)
I would have made a screen shut, but the links suggestions doens work anymore. But if you are at the bottom of the screen, I think the box shouldnt be right under word – then you cant see the box. Christian75 (talk) 21:01, 21 August 2013 (UTC)
The box will always be visible. If you are at the bottom, when popping-up it will autofocus your window so that you can see everything. That's why we need to know your OS/Wikipedia skin/browser (and its version) in addition to the title of the article. Thanks, --Elitre (WMF) (talk) 08:23, 22 August 2013 (UTC)
After editing, Navigation Popups isn't reloaded
The following discussion is marked as answered. If you have a new comment, place it just below the box.
AFAIK, if a gadget are not working with VE, it's the gadget that should be fixed if people want/need to use it with VE (this is what happened until today - you can also see it confirmed in James' comment [13]). The good news here is that someone (our very own Brion Vibber!) has already requested an in-built Navigation Popup feature here. Thanks, --Elitre (WMF) (talk) 16:04, 20 August 2013 (UTC)
Actually, I think this sounds like a reoccurrence of T53565 - if gadget works before a save it should work after a save as well without needing a restart. As I can duplicate this in Firefox 23 on Linux I've reopened the bug. Thryduulf (talk) 15:31, 22 August 2013 (UTC)
Slightly scrambled wikilink from IP
The following discussion is marked as answered. If you have a new comment, place it just below the box.
I've commented on that bug, giving the example of [14]. This is caused by changing the capitalisation of the first character of a link. Thryduulf (talk) 15:46, 22 August 2013 (UTC)
Scrolling
The following discussion is marked as answered. If you have a new comment, place it just below the box.
I am using Google Chrome on OS X Mountain Lion. When I click "Edit beta" on a section, the browser scrolls down to a random place in the page. I am assuming this is caused due to several things being removed such as the summary, but it is inconvenient to find the section I was attempting to edit. It also scrolls randomly when I press the link for feedback. I have to scroll again to find the feedback dialog. But overall this is a great idea for unsophisticated users :)4 173.73.156.63 (talk) 15:05, 21 August 2013 (UTC)
The first issue is caused by the Table of contents not displaying in VisualEditor, which alters where the desired section is displayed. VE does scroll to the desired section, but only when it has completed loading and only if the user has not scrolled while it is loading. I've reported this as T55217. Thryduulf (talk) 16:07, 22 August 2013 (UTC)
Maybe known - but this template confuse VE
The following discussion is marked as answered. If you have a new comment, place it just below the box.
This "template" makes VE show nothing...
{{Persondata Metadata: see Wikipedia:Persondata.
|NAME = |
DEATH = }}
From a real page - I would fix a broken template. And the output isnt nothing. Btw. if the template wasnt broken, its near impossible to find {{persondata}}) template on a page (with VE), and you have to know that its there (somewhere). Christian75 (talk) 21:17, 21 August 2013 (UTC)
There is a request here to make VE handle invisible templates better. (This one though is particular in that 1) "Adding the Persondata template to a biographical article doesn't affect its normal display, since the information isn't meant to be read by human beings and remains hidden unless users change their personal stylesheet specifically for it to appear" 2) you can definitely find empty occurrences of it in articles, and this does not mean that something is broken.) Thanks, --Elitre (WMF) (talk) 08:48, 22 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
If I edit a blank page, press on the number list or bullet list icon and then press enter, the page remains blank but I have no cursor. Then other strange things start to happen. Pressing the link icon does not seem to do anything. I can press some icons (transclusion, references, etc) and they will appear, but if I then exit it, pressing it again or any other icon does nothing. Undo works though. FF 23.0.1 Win7. --Atethnekos(Discussion, Contributions)21:27, 21 August 2013 (UTC)
Start with a blank page. I type in "*". I get a wikitext markup warning. Then I type in "</nowiki>" and then "'''test'''". When I save, I'm left with "*test</nowiki>" with the bolding. --Atethnekos(Discussion, Contributions)22:25, 21 August 2013 (UTC)
I got<nowiki>*</nowiki>'''test'''</nowiki>, which renders as *test</nowiki>. The bold-faced formatting is objectively wrong, but it's the "23" that mystifies me. Can you reproduce this? Whatamidoing (WMF) (talk) 02:44, 22 August 2013 (UTC)
I think I need your help again here :) I get Sherry's result, but I am totally fine with it, since I wanted that word to be bold, and it is just the asterisk that is wrapped in nowikis. So why would one write something and then add the /nowiki tag? The correct tag that should be used to break wikimarkup is <nowiki /> , and it should be added before, not after. --Elitre (WMF) (talk) 12:49, 22 August 2013 (UTC)
Well, I guess it is fine if that's how you want it to render, I'm not trying to say that that is not the case. I was just guessing it was a bug, because what I see is not what I get. In VE I see *</nowiki>'''test''', but after saving in view mode I end up seeing *test</nowiki>. But then after saving, if I open VE again, what I see is not what I saw in VE before I saved. So somehow saving made changes. When I type in '''test''' elsewhere in VE it doesn't make it bold when in view mode, it renders the same as it renders in VE. And I certainly wouldn't expect the string </nowiki> to all of sudden move to the end of the text, when I typed it in the middle. To me it just looks like a normal bug concerning sanitizing the user input. But I don't know about these things. --Atethnekos(Discussion, Contributions)15:09, 22 August 2013 (UTC)
if you write this in VE: You forgot to close with </nowiki> '''Its ok''' – it becomes (in the article): You forgot to close with Its ok</nowiki> (and as wiki source - see here)</nowiki></nowiki>) Christian75 (talk) 15:19, 22 August 2013 (UTC)
e.c. - Of course, the word changing position was not expected for me as well, and I did not mean that you should get a bold word since VE works differently for that, but I assumed that somehow we put VE in a mixed state where it nowikied the asterisk and accepted the '''. What I need to understand is a) the purpose of that nowiki tag - I assumed you wanted to use the one I mentioned instead, since the one you used should feature an "opening" nowiki tag before, in order to work properly; b) the expected outcome of your operation; c) how VE screwed it up :) It must be interesting for the devs to hear of similar tests, what I try to understand instead, not being a developer myself, is if what I read is a highly critical bug or a situation that will probably never happen again (since it is due to a "closing" nowiki tag being added without its "opening" one). --Elitre (WMF) (talk) 15:26, 22 August 2013 (UTC)
Sorry, I'll try to answer: a) the purpose of that nowiki tag was to display as a string of characters. b) I would expect the outcome to be that when viewing the page the page would have "*</nowiki>'''test'''". c) VE saved the string such that in view mode the two sub-strings of "'''" were removed, and caused the sub-string "test" to become bolded, removed the sub-string "</nowiki>" in the middle of the string and added it to the end of the string. These answers are with a caveat: I'm not sure what VE is supposed to do, I merely guess that it is supposed to save strings of characters so that they appear when viewing the page as they appear when editing in VE, but I don't know that for sure. (Also I used double quotation marks here to set out the characters, but I've been inconsistent previously). --Atethnekos(Discussion, Contributions)15:49, 22 August 2013 (UTC)
I think we report this as a bug that VisualEditor (or Parsoid?) is failing to notice that someone has added a nowiki tag. If I type in a nowiki tag today, by itself, it converts it to <nowiki>. It's only if you're additionally triggering the nowiki markup for that line (e.g., by starting the line with an * or triple single quotes) that the nowiki code isn't processed safely. I think we need to add a bug for this. Whatamidoing (WMF) (talk) 18:33, 22 August 2013 (UTC)
Link and insert " " into anchor
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Start with a blank page, type in "Hello", select the text make it a link to France. Move cursor into middle of "Hello" type in " ". When I save I'm left with "Hel lo" with the non-breaking space rendered. No wikitext markup warning. --Atethnekos(Discussion, Contributions)22:49, 21 August 2013 (UTC)
NBSP is a variant of the space character, not a wikimarkup thing, so I think it is ok that it does not trigger the warning, and instead does what is expected - adds the non-breaking space, if that's what you needed to have in that location. --Elitre (WMF) (talk) 10:59, 22 August 2013 (UTC)
You added a code that you know adds a non breakable space and that should not been seen after saving, and that's what you get in the link after you save. If that was not the outcome you expected, can you then describe it? I see inconsistency between what happens to plain text and what happens to links, yes. I'll try to learn more about this. --Elitre (WMF) (talk) 14:42, 22 August 2013 (UTC)
Yes, this looks like a bug in Parsoid. Parsoid should consistently save it as &nbsp; in both cases in wikitext so that it displays as when viewed. Thanks for the report Atethnekos. Ssastry (talk) 15:19, 22 August 2013 (UTC)
So I made this page with VE: User:Atethnekos/sandbox2. It looked fine as I was making it. However, the Sfn template within the reference doesn't render in view mode (to be expected), but it does in VE. Nothing while placing this template within the reference in VE suggested that it wouldn't work.
Also, when first making it, the Vcite book template would render properly in VE, but now going to VE with the page after having saved, it doesn't render properly. It shows a <span> tag. --Atethnekos(Discussion, Contributions)00:35, 22 August 2013 (UTC)
Oh, thanks. That bug seems strange to me, though. Is Sfn really not supported? I have no trouble creating them in VE, like most other templates. They seem to work fine, except as here when an Sfn is placed within a reference, which makes VE go wonky, but that's all it does. --Atethnekos(Discussion, Contributions)15:16, 22 August 2013 (UTC)
If memory serves, sfn is now "supported" in the limited (but important) sense that VE no longer makes an enormous mess of the page when it's present.
If I understand this question correctly, it isn't really about sfn, but about nested refs, so putting something like this into VisualEditor:
Chocolate tastes better than other foods.<ref group=note>Specifically, experts agree
that chocolate tastes better than whiskey.<ref group=source>
Expert Council (2013) ''Important reliable source''.</ref>
'''Notes'''
{{reflist|group=note}}
'''Sources'''
{{reflist|group=source}}
produces expected and desirable results in VisualEditor:
Chocolate tastes better than other foods.[note 1]
Notes
^ Specifically, experts agree that chocolate tastes better than whiskey.[source 1]
Sources
^ Expert Council (2013) Important reliable source.
until you save, in which case it breaks completely:
{{quotation
|Chocolate tastes better than other foods.<ref group=note>Specifically, experts agree that chocolate tastes better than whiskey.<ref group=source>Expert Council (2013) ''Important reliable source''.</ref>
Notes
Sources
}}
I'm not sure whether this problem is truly a VE problem or a problem with the normal interpretation of wikitext. (They ought to match, but what should we do with sfn/any ref inside a ref? Which one's behavior should be changed?) I'll ask around. Whatamidoing (WMF) (talk) 18:20, 22 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
When trying to correct a lower-case letter to a capital letter at the beginning of a link, I deleted the lower-case letter and found I couldn't type a capital letter and have it become part of the link, nor could I seem to extend the link over the capital. Eventually, I typed the capital after the lower-case letter and then deleted the lower-case letter. It might be good to have some way to extend a link over adjoining letters/words/text. Mount Flatten (talk) 05:31, 22 August 2013 (UTC)
bugzilla 49603 has been in the queue since mid June and it's unfortunate how to handle this is still getting kicked around. HTML comments have long been used to deal with the persistent addition of wrong information to some articles. For example, General of the Armies has several along with an edit-notice. --Marc Kupper|talk17:47, 22 August 2013 (UTC)
Picture
The following discussion is marked as answered. If you have a new comment, place it just below the box.
This is T52100. There has been discussion of cases where the intention is to delete the header and then replace it with a different one, recent comments though have pointed out that this is never the case when the entire section is deleted too. Your explicit mention of what you expected to happen is useful and should help determine what the desired behaviour from VE is (a prerequisite to fixing undesired behaviour), thank you. Thryduulf (talk) 01:59, 23 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
If I start with a blank page, type in "<br>", select the entire text, press the link icon, select say "France" as the link, upon exiting the link dialog I am left with a link to [[France]] but the anchor is shortened to "<b". I don't get any "Wikitext markup detected" warning. --Atethnekos(Discussion, Contributions)21:55, 21 August 2013 (UTC)
That's probably because it's an HTML tag - if it was saved, it would be wrapped in nowiki tags. I have no problems in reporting this as well, but I am wondering why one would add a wikilink not just to a br tag, but to a word between inequality signs. What I would ask instead is, since they are later going to be wrapped in nowiki tags anyway, that HTML marks are recognized as such and that they trigger the warning. Thoughts, Atethnekos? Thanks, --Elitre (WMF) (talk) 10:43, 22 August 2013 (UTC)
Assuming that inequality signs are HTML might be a problem for writing equations like "α is <β and >γ" or "Normal total cholesterol is <240 and >150 mg/dL". Whatamidoing (WMF) (talk) 17:47, 22 August 2013 (UTC)
It used to be possible, in VE, to link to another section of a page (say, Bank#History). Now, when section information is added, in the Link/Hyperlink dialog box, VE just deletes it when the user presses [return] or exits (in any way) that dialog box.
I realize this isn't the right place to ask, but really, does the VE team do any systematic testing of bug fixes before they roll them out? Is the QA team (of whom I've never seen a mention in these pages, but I know exists) involved in testing VE bug fixes?
(Please pardon my frustration - I'm trying to keep the User guide up-to-date; now it looks like I'll have to delete (or hide, I guess) information about some functionality that was in place but no longer is. Why this VE not an opt-IN beta?) -- John Broughton(♫♫)04:57, 22 August 2013 (UTC)
I added to [18] and will ask on IRC later (timezones, you know...) I know that some QA people work on VE since it's in their reports, but that's all I know. And yes, there are many tests and sanity checks before each deployment, I can only assume here that this is a case of "fixing something that will break something else", only you can't possibly know what, I guess. Regards, --Elitre (WMF) (talk) 11:37, 22 August 2013 (UTC)
I've reported this separately as T55219 as it is a regression that removes previous functionality (T52881 is an enhancement request for proper handling of section links). It isn't possible to know everything that will be broken by an update, but this is something that should have been tested pre deployment). Thryduulf (talk) 16:29, 22 August 2013 (UTC)
Guys, yesterday an emergency patch was applied for issues related to wikilinks. I am not sure it is related, but I am pretty sure that you can't possibly test anything against all the possible malfunctions. Just my 2c here. --Elitre (WMF) (talk) 16:40, 22 August 2013 (UTC)
No you certainly can't test everything against all possible malfunctions. You can and should test (almost) everything against a finite number of possible malfunctions though, you just have to decide which ones those are based on the liklihood of breakage, scope of consequences of any breakage and ease of testing. For a patch related to links in VisualEditor, I would expect the ability to enter section links with VisualEditor to be on the list of such tests as there is at least a moderate chance of impact, at least moderate consequences of a break and testing being very quick and easy. This isn't something worth arguing over though - the breakage happened, lets just do what we can to encourage the devs to fix it :) Thryduulf (talk) 18:10, 22 August 2013 (UTC)
Yes, this is T53422. It's been hanging around unassigned and unprioritised since mid July though, so I've left a comment there to remind people like James of its existence. Thryduulf (talk) 01:45, 23 August 2013 (UTC)
Do you know there's a workaround for this? (Hint) - I added this on some VE pages on it.wp and also on a bug that I thought was related, will need to find out which one. --Elitre (WMF) (talk) 07:58, 23 August 2013 (UTC) PS: I thought it was this one.
I'd like to understand if in this case something can/should be done to the template itself to avoid this, before reporting this as a bug. Thanks, --Elitre (WMF) (talk) 10:28, 23 August 2013 (UTC)
(edit conflict) Using Firefox 23 on Linux with Monobook I see the indented text on the live article exactly as per the screenshot. Elitre, your sandbox template doesn't display anything at all in VE for me. Thryduulf (talk) 10:54, 23 August 2013 (UTC)
Thryduulf, I don't think Magioladitis' edits fixed the template, since I can still reproduce what happens in the article as well. But I correctly see what is in my sandbox with both FF and Chrome... --Elitre (WMF) (talk) 11:15, 23 August 2013 (UTC)
I think you finally fixed the right space in the template (546bytes, just like my sandbox :) ), and we'll see if a purge solves this for Thryduulf too. --Elitre (WMF) (talk) 11:30, 23 August 2013 (UTC)
Hey Marc Kupper, you said "the edit worked", but that edit is not tagged as made with VE (and there's only a VE edit in that article made in July). So VE gave you an error before saving, you chose the source editor and used that instead? --Elitre (WMF) (talk) 16:56, 19 August 2013 (UTC)
I did the edit in VE, clicked the save-page button, gave a reason, and clicked 'Save Page.' As I knew it was a large page I walked away. When I came back the error was there. I cancelled out of VE, and did the edit in source mode. I've copied the page content to User:Marc_Kupper/sandbox2 and will try the VE edit again there. --Marc Kupper|talk21:39, 19 August 2013 (UTC)
It took 74 seconds to load the page in VE, I made the change, save-page, give a reason (wikilink - testing VE), save-page again. After 1:45 (105 seconds) I got "Error: Unknown error" in the lower part of VE's edit-summary box. The save-page button is grayed out.
I don't think the actual edit I did matters. If someone wants to reproduce using my sandbox then the edit was in the last paragraph of the lead. Where it says "...Essential Art House, Eclipse, and Merchant Ivory Collection..." I changed "Eclipse" to [[Eclipse (DVD)|Eclipse]] by double-clicking on Eclipse to select, control-K to bring up the insert/edit link box, appending " (d" to the link-to value, click "Eclipse (DVD)" in the list of offerings, and then press <enter> a couple of times to close out the box. I suspect you can make any change you want. --Marc Kupper|talk22:06, 19 August 2013 (UTC)
After documenting how I did the edit I tried the save again and again got the error. It happened 1:44 (104 seconds) after clicking save. I suspect the 105 seconds above is simply because I was a bit slow reacting as this time I was waiting for the error right around the 1:45 mark. --Marc Kupper|talk22:06, 19 August 2013 (UTC)
I then did the following tests
I replaced all non-alphabetic characters with the letter "x" and can edit the page with VE. It appears the issue is with something in the page content, possibly combined with the page size.
I removed all 'ref' tags. Saving from VE still fails after 1:44
I don't have time to debug this further at present - particularly as we now have two VE issues. The next step is to revert back to 22:48, 19 August 2013 and to then see if I can narrow it down from there. --Marc Kupper|talk23:11, 19 August 2013 (UTC)
Hello - I do believe there remains an issue with very long pages. I dared to try VE on 2009 flu pandemic timeline, which is ~227kb, and a) encountered a "your edit might have been corrupted" message, indicating that I should check my edit and b) the inability to bring up the edit diff (timed out). Now, this article is known to be long enough to warrant splitting, but it would be useful to know the current confidence limits around page length and the ability to edit same. Is it dependent upon local environment (i.e. PC configuration and memory allocated to browser)? Or is there a server side known performance limit? Thanks for considering this. --User:Ceyockey (talk to me) 01:28, 23 August 2013 (UTC) P.S. I did not try hard to implement my changes and did check to see if I had put an edit into the history which might have needed reversion; no edit in edit history was recorded after my truncation of the process, which was reassuring.
The following discussion is marked as answered. If you have a new comment, place it just below the box.
I was in the Marine Corps for 5 years, 7/69 to 2/74 and never heard it referred to as an "eight pointed" cap. That name might be very recent. 139.84.48.251 (talk) 20:15, 24 August 2013 (UTC)
This page is for feedback on VisualEditor, our new editing interface. For feedback on a specific article, please head to that article's talk page. --Cryptic C62 · Talk23:45, 24 August 2013 (UTC)
Edit Buttons
Thanks for switching the buttons. unfortunately the way its implemented leads to (possibly right now only the english is different) the button being in a different place each time I switch between language versions.--Saehrimnir (talk) 16:10, 23 August 2013 (UTC)
Yes, it's a bit awkward. We've also heard some complaints from people who had just gotten used to the old order, when the new order was imposed on them, so they had to re-adjust. But this is how the vocal participants of the English Wikipedia want the tabs ordered, so that's what's happening here for now. Similar discussions have happened at a couple of other Wikipedias, and they have been less inclined to shuffle the tabs around for exactly these reasons. Someday (probably months from now, maybe years), the English Wikipedia will likely switch back to the default arrangement, but for now, this will be a problem for some people. If it's seriously disruptive to you, then I believe that someone could create a script that would change them back to the default just for your account. Whatamidoing (WMF) (talk) 18:06, 23 August 2013 (UTC)
(e.c.) I think it might lead to confusion, so I guess at some point there will probably be the need to "think globally" and take a decision about the position; this might be the same for all wikis, while each wiki might still label them as they see fit - my2c here. --Elitre (WMF) (talk) 18:11, 23 August 2013 (UTC)
I was one of the advocates for changing them back from the moment I discovered that this was done so I am happy now by switching it of in every Language but en since I only do source code stuff in every other anyways. I just would have liked to be able to test/use it further in the german version also.--Saehrimnir (talk) 14:05, 24 August 2013 (UTC)
@Saehrimnir: I was under the impression that in the German version of Wikipedia, you can use VisualEditor - but you need to select it (opt-IN) via preferences. Is this true? -- John Broughton(♫♫)01:53, 25 August 2013 (UTC)
Yes, you can of course activate it manually, but if you think VE should be default on de.wp as well (at least, this is my impression reading your words), it might be useful that you let that community know it. Regards, --Elitre (WMF) (talk) 10:48, 25 August 2013 (UTC)
No that is not what I meant, because I know and am capable to activate it there, but its still no use because the buttons are still in the wrong order. Wht I meant you should have made the change of positions globally because in this way all the things are fracturing. The fact that the same field in german wikipedia if checked activates the VE and in all other wikipedias deactivates it is another symptom. I that said I really like that you are finally doing a Visual editor I am just not happy with the fact that you try replace the the normal editor with it while it does not have some core capabilities like table formatting and special characters. Sorry for keeping you away from fixing and maturing this good feature with my confusing comment. --Saehrimnir (talk) 14:22, 25 August 2013 (UTC)
Disappeared image caption
The following discussion is marked as answered. If you have a new comment, place it just below the box.
After a lot of experimentation (see [19]) I've discovered that any caption with the lowercase words "page" and "commentary" in that order, regardless of anything else in the caption, is not rendered in VE. I've reported this as T55312, thanks for the spot that was an interesting bug to narrow down! Thryduulf (talk) 10:14, 25 August 2013 (UTC)
Further testing shows that it is "page " (including the trailing space) followed by "comment" that triggers the bug. Thryduulf (talk) 11:18, 25 August 2013 (UTC)
Wow, this is a fascinating one. I'm going to play around with this later today and see if I can find any other invalid strings. --Cryptic C62 · Talk13:36, 25 August 2013 (UTC)
Further further testing shows that the error is caused by "page " (including the space) followed by some text, or "page=" followed by any text or nothing. --Cryptic C62 · Talk20:38, 25 August 2013 (UTC)
I'll certainly second that comment! I've copied Cryptic's comments to bugzilla. Earlier I discovered that it is confined to image captions, and that the behaviour of captions entered in VE is at least as odd if not odder!
If you edit or enter an image caption in VE with the words "page comment" in you can see the caption in that edit.
Saving and reentering VE exhibits odd behaviour - the caption of the image entered in VE is not visible as I predicted. However the edited caption of an image that was already present remains visible. This is confirmed on a subsequent round trip in and out of VE, but I can't test on other systems / browsers than Firefox 23/Linux. See [20] The image of Gloucester Docks at the head of the section was the one with the edited caption. The image at the end of the preceding section (the prospect of Derby) was added in VE. Thryduulf (talk) 23:40, 25 August 2013 (UTC)
Null edit review changes issue.
The following discussion is marked as answered. If you have a new comment, place it just below the box.
So I put a space and then a backspace. Go to save, review changes to check and make sure it is a null edit, then it goes to this "processing" dialogue but then it shows "Could not start the review because your revision matches the latest version of this page." So then I press the little back link on the dialogue, but it just goes back to the processing dialogue. If the page is small, the processing is really quick, so before I can even press back again, it goes back to the "Could not start" warning message. Even if I do manage to press the back a second time quickly, it will only stay at the save dialogue for a split second and then again bring me to the warning message, although then pressing back does take me to the save dialogue securely. FF 23.0.1 Win7. --Atethnekos(Discussion, Contributions)04:35, 25 August 2013 (UTC)
Confirmed on Firefox 23.0 on Linux and reported as T55313. As a workaround, the ^ link takes you back to the editing screen as expected, and you can then relaunch the save dialog. Thryduulf (talk) 10:30, 25 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Is there a page, or perhaps a query that could be run in Bugzilla, that would tell me what the most recent update was to VE, and what bugs were intended to be fixed by that update? That way I could check the bugs that interest me that should have been fixed. Mike Christie (talk - contribs - library) 15:31, 25 August 2013 (UTC)
In general, developer status reports are at mw:VisualEditor/status. The last status report includes a link to "all Bugzilla bugs closed in this period", a bugzilla database report. You can create similar database queries in bugzilla yourself.
(You'll find a link to this page of developer status reports on the VE navigation template, which is on this Feedback page, but set to not show unless requested; you can see it in its natural state at WP:VE. ) -- John Broughton(♫♫)16:06, 25 August 2013 (UTC)
It's true, really. There are still dozens upon dozens upon dozens of bugs in it, and nobody on this site likes it or appears to find it trustworthy. The old wikitext editor was so much better and more reliable. I don't know why the WMF thought it was a good idea to release the VE while it is still in beta testing. It's just like commercial software; think about it! Would developers want to release their products while still in beta? Of course not! Because all that does is lead to the company making significantly less money than expected, and people not ever wanting to buy their products, because they will think that the developers are lazy, impatient, and always rushing their products before they're even ready. BTW, I have VE completely disabled for my account. Sometimes the stuff that's designed to be convenient just doesn't work. Anyway, that's my feedback on VE. Interlude 65 (Push to talk) 15:47, 25 August 2013 (UTC)
Without commenting on whether or not it should have been released, I think it should be pointed out that it's not the case that "nobody on this site likes it or appears to find it trustworthy". At least one editor (me) likes it, and I find it trustworthy enough to use on most of my content edits. Mike Christie (talk - contribs - library) 15:53, 25 August 2013 (UTC)
OK, maybe not everybody hates it, but from what I've heard and seen, I'd say (roughly) about 95% of the users here on Wikipedia do, and would much rather edit using the wikitext editor. Further, just what are you insisting on the part where you said that "it's trustworthy enough to use on most of my content edits"? Can't you see (or at least heard of) all of the commotion VE has been causing on this site? Users have been reporting numerous problems with it, and I feel like all it's doing is hurting the world's largest, open source encyclopedia. Interlude 65 (Push to talk) 19:14, 25 August 2013 (UTC)
I just meant that I use it for most of my content work (currently radiocarbon dating), and while there are certainly bugs and missing features, I've found it a net positive for editing that article. I'm aware that there are bugs that cause unintended consequences including loss of text, but I haven't run into that myself. I find that I'm starting to default to using it, only switching to wikitext when I know VE can't handle it -- primarily math markup, and some punctuation issues. Mike Christie (talk - contribs - library)
For what its worth Interlude me and about 500 other editors agree that VE sucks but the 5 or 10 that really like it keep insisting there is nothing wrong with it and refuse to do the right thing and make it opt in only. I'm not even saying we should stop working on it, but in its current state its too much of a mess to be pushing new users to it Kumioko (talk) 19:39, 25 August 2013 (UTC)
Yes, I know I'm in a minority; I did, rather belatedly, !vote in the RfC, and I see the direction that's going. That's fine; my preference would be otherwise, but RfCs are there partly to avoid minorities making decisions. My objection is simply to the blanket statements that I see occasionally: "nobody likes it"; "it has no benefits"; "everyone wants it to go away". Those aren't true. In addition, I think that arguments made acknowledging minority positions tend to sound less like rhetoric and more like reason, and so, to me, anyway, more convincing. Mike Christie (talk - contribs - library) 19:54, 25 August 2013 (UTC)
The VE is still there for those that want to use it. That's a good thing: it's already useful for some types of simple edits, and it's getting slowly less painful to use over time for slightly more complex edits. However, in spite of the improvements, it's still essentially unusable for non-trivial "technical" Wikipedia editing, where editing the Wikitext is still really the only practical way to go. I look forward to seeing further improvements, but at the current rate of improvement, I suspect it may take years before it's ready to be made the default tool for beginner editors. -- The Anome (talk) 20:03, 25 August 2013 (UTC)
Wikilink problems
When I edit the end of a wikilink (not the link itself, but the text displayed), such as changing it to a plural, the actual link does not continue over the new characters. Also, I want to create a line break in the middle, the break and any text after it are not included in the link. Is there a patch being developed that will allow editors to choose whether they want the link to extend over some new text or not?--¿3family6contribs20:05, 25 August 2013 (UTC)
I think the stage that they're at is realizing that it's complicated. People want:
The way to do it at the moment is to enter your new text, select everything you want to appear in the link and then load the link dialog (using the button or ctrl+k) and confirming the link target. While possibly not the best, this reliably includes what the user wants linked and nothing else. Prior to a couple of updates ago, it was nearly impossible to end a link as everything you typed apart from a linebreak was included whether you wanted it or not. That was far more disruptive than what we have now. Thryduulf (talk) 23:53, 25 August 2013 (UTC)
Fixing Badly Constructed Tables Messes Up Contents Below It
Editing (in order to fix) badly constructed tables like in this page (Android_version_history, there were two rows with one left column at the end of the Android 4.3 table) shows the content below the badly constructed table within the table. PhistucK (talk) 08:14, 23 August 2013 (UTC)
It took me a while to understand this, but viewing the end of [21] shows the error. I'm not sure this is actually a VisualEditor bug, as VE is correctly displaying what the source is telling it to as |-} is not a tag to close a table. The issue is that the php parser treats the specific malformed markup in [22] as a correctly closed nested table i.e. at the end of an otherwise correctly formed table
|-}
{|
|}
Is treated as
{|
|}
|}
Whereas if there is any content between the |-} and |} the php parser treats it as the code says it should. Consequently I'm not really sure what VE or Parsoid should be expected to do when it encounters this? Pinging Ssastry, who may have some useful input here.
As an aside, the markup here appears to be the result of incompletely cleaning up this VisualEditor edit on 27 July. That's one of the known table bugs, but I can't remember which, and so has either been fixed or is being worked on. Thryduulf (talk) 09:57, 23 August 2013 (UTC)
I think the fixup is being done by Tidy which cleans up bad HTML generated by the PHP parser. It seems to close unclosed tables at a heading tag (<h1> and others). But, given that we've run into more several instances of unclosed tables, I think we (Parsoid) could think of implementing that behavior as well. However, it is a lot more trickier in our case since the table would have been closed automatically based on HTML5 specs by the HTML library we use (and unless the library is buggy, unclosed-tables seem to be handled differently than Tidy). So, to replicate Tidy's behavior as in the PHP parser pipeline, we would have to detect these automatic fixes, undo them, and close it before headings. That seems like a lot of work and hackery for unclear benefits when there are other higher-priority things to deal with. At this time, I am inclined to say that unclosed tables are best fixed up by editing source. Sounds reasonable? Ssastry (talk) 16:38, 23 August 2013 (UTC)
I think that malformatted tables ought to be properly formatted. I wonder whether someone like User:MZMcBride could produce a list of tables that end with
(edit conflict) At some point Parsoid should be able to cope with unclosed and malclosed tables, but as it sounds like a lot of work I think setting that as a low priority task seems fine for now, as long as it doesn't destroy ones it encounters. When table editing comes to VE things may change, but hopefully the tools wont allow the creation of an unclosed table - I can't imagine a use for them outside templates (cf T53043 (comment #8)/T54488)? Thryduulf (talk) 18:16, 23 August 2013 (UTC)
I agree that "start a new row" and "close table" are valid tags. But why should "start a new row—close table" be considered a valid sequence? "Start a new row" ought to be followed by a new row, not by a sudden end to the table. Whatamidoing (WMF) (talk) 18:23, 23 August 2013 (UTC)
It should be considered acceptable because it has produced tables that render correctly since pipe syntax was created, thus as noted in the above section, people will continue to write tables that way. Even though the html doesn't validate perfectly, html tables ending with a blank <tr>...</tr> line render fine in browsers - e.g. this test page, so VE needs to able to deal with it on an ongoing basis. Thryduulf (talk) 18:50, 23 August 2013 (UTC)
This is a philosophical issue that I see the VE team not quite grasping: the way that wikitext is pretty much parsed today is correct by definition, and is the behaviour they need to emulate. WYSIWYG only works if you actually present the same way that the established wikitext parser presents, or What You See Is What A Developer Thought You Should Get. No one needs a WYISWADTYSG editor.—Kww(talk) 19:06, 23 August 2013 (UTC)
I don't think that "how it works today" is really what we should be aiming for. "How it works today is correct by definition" means that T22707, the "Thou may not add citations to explanatory footnotes" bug, should never be fixed.
If we can get perfectly validated HTML, then why should we preserve invalid table formatting? I'm thinking that Parsoid and VisualEditor should quietly produce valid HTML in these tables (without making a mess, which is what they're doing now). Whatamidoing (WMF) (talk) 19:36, 24 August 2013 (UTC)
The point is that if a given string of wikitext produces something that works and appears as intended, whether or not the HTML is valid, Parsoid and VisualEditor need to expect to encounter that wikitext on an ongoing basis and accept it as valid input. What you do to it to produce valid HTML is up to you, as long as the wikitext is preserved on roundtripping.
Tables ending with trailing new line are a good example of this - the wikitext produces a table that looks and works as expected. VE and Parsoid need to deal with it as valid input and work with the resulting table in exactly the same way as a table that does not have this feature.
Tables with a malformed closing tag followed by open and closing tags does not produce a table that looks or works as expected. In the long term VE should offer a way to fix this, either manually or automatically. In the short term VE and Parsoid just need to not damage the article when they encounter it - conceptually they need to recognise it as a malformed table and leave it exactly as it is. Thryduulf (talk) 08:54, 25 August 2013 (UTC)
That's my question: Why should we preserve the (busted/worthless/invalid-HTML-producing) wikitext on roundtripping, when we could actually fix the wikitext, so that it does not contain a pointless new-row tag? Why not make it 100% right in wikitext as well as in other forms? Why preserve the pointless wrong stuff? Whatamidoing (WMF) (talk) 22:11, 25 August 2013 (UTC)
Because as far as the user of wikitext is concerned it isn't wrong, afaict doesn't produce invalid html, and isn't regarded by everyone as pointless (see comment in the above-linked section). Thryduulf (talk) 00:00, 26 August 2013 (UTC)
Visual separation (the only hypothesized benefit) could be achieved by leaving a blank line. I think we should kill these. (We definitely shouldn't be creating a big mess when we encounter them, which is why we filed that bug, but I think it would be preferable for them not to exist, per Adam's suggestion in that same section.) Whatamidoing (WMF) (talk) 17:25, 26 August 2013 (UTC)
Toolbar icons style
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Status
New:
Description
To be quite honest, the first thing that I see wrong in the visual editor is the black-and-white style of icons, similar to what Google products uses. It is not 1980s when everything was black-and-white, nor it is 1990s when people used 256-color icons; it is 2013.
Classic editor toolbar with clearly distinguishable icons and their meanings.
Another classic style toolbar used on Wikipedia before.
An Open-Office, a word processor, toolbar in 2007.
An open-source tool toolbar in 2008.
VisualEditor toolbar in 2013.
I believe it is important for accessibility to at least let users choose from a set of themes for the VisualEditor toolbar, if not alter the default theme.
Back from a fortnight away, so I'm not up to speed on all recent developents, but decided to have a go with VE while stub-sorting.
Editing Parvardigar (Pete Townshend song), I fixed the stub, wanted to add {{unref}} after the navigation hatnote. Put cursor in front of the "P" of the lead sentence, added the template, all looked fine. Went to save it, looked at "Review your changes", and the word "Parvardigar" had been deleted, replaced by the template. Closed the "save page" window, had another look at the work in progress: the {{unref}} displays, and so does the word "Parvardigar": so the word seems to have been deleted, but is still being shown in the displayed version while I'm editing. Ouch. Will save the edit, then go back and fix it.
... Interesting: when I've saved the article, the word Parvardigar is missing, immediately. The change to stub template and resulting category don't appear till I reload the page. Quirks of VE. PamD16:34, 25 August 2013 (UTC)
And this is reproducible. Go to my VE sandbox and try to insert a maintenance template after the navigation hatnote and before first word of text. The natural way to try is to put cursor before first word of text and add template: the workround is to put cursor there, hit return to get a blank line, arrow up to get onto that blank line, and then add template. PamD21:34, 25 August 2013 (UTC)
Actaully, the problem is that inserting any template before a bold, italic or linked word deletes that word. It doesn't seem to matter what else is around it. I've reported this as T55334. Thryduulf (talk) 00:38, 26 August 2013 (UTC)
It also happens to multiple words (e.g., all bold-faced words) and to formatted or linked words that you add immediately after a template. Putting a space after or hitting return between the template and the text seems to work correctly. Whatamidoing (WMF) (talk) 17:39, 26 August 2013 (UTC)
hlist in infobox, File:Image, and tables
I made this User:Atethnekos/sandbox4 as a demonstration. If the hlist template is used in an infobox or a table like on the page, when I go to VE, the list will end up be extended far into the page. If it's used with [[File:Image]] as on the page, the list will end up being cut off, and then some weird things will happen if I try to click on the hlist template (e.g., the page will be extended to right and my browser will give a horizontal scroll bar). FF 23.0.1 Win7--Atethnekos(Discussion, Contributions)19:33, 25 August 2013 (UTC)
I took a poke at the subscripting and superscripting feature now available on mediawiki.org, and I think I may have encountered a bug. First, I noticed a strange behavior where anything I typed at the end of that third line, if I then hit enter, it would be duplicated in the fourth line, and my cursor would move to the fifth (blank) line. I then took a look at the wikitext generated by VE, and it looked odd, so I copied it into a wikitext editor, and got a rather different looking result than VE was showing. Also, upon saving with VE, I got this result, which is the same as copying into wikitext editor, but not what VE was showing me. Chris857 (talk) 20:54, 25 August 2013 (UTC)
Testing this now. Note to self: when I created the sandbox to test this, I got the message that it was created only when I hit Edit again to change that text. --Elitre (WMF) (talk) 13:10, 26 August 2013 (UTC)
Ok, I don't think it has to do with the new features. Proof is, I can reproduce (on Mediawiki) the same bug without using them. You just need to add quickly casual sequences of words, as if you were vandalizing the page. In the linked diff I kept writing on the third line, it was VE which splitted what I wrote on more lines. I was also able to reproduce the difference among the content you "write" and the one which is saved. Filing this now. --Elitre (WMF) (talk) 13:27, 26 August 2013 (UTC)
After editing a page in beta mode on the iPad, the format of several links, which have not been edited by me, was changed (HTML hyperlink tags added), prompting an error message on saving the page. The corrupted links can be found in my edit (undone afterwards) of the EMD SD90 MAC article. Wetzgau21 (talk) 14:51, 26 August 2013 (UTC)
Hi, sorry, didn't know that. But it would be great if there would be a workaround for this problem without having to change any (default) settings on iPads. Wetzgau21 (talk) 21:21, 26 August 2013 (UTC)
Don't be, Wetzgau21, you were not required to know about this, of course! I actually found out about this yesterday because I noticed NicoV's comment on a related bug. Hope this gets fixed soon :) --Elitre (WMF) (talk) 20:29, 26 August 2013 (UTC)
Thanks for your message, and for noticing and fixing the problem in the article. In this edit, your iPad apparently thought that the numbers were telephone numbers. We'll need to find a way around this. Whatamidoing (WMF) (talk) 17:45, 26 August 2013 (UTC)
change if format
The following discussion is marked as answered. If you have a new comment, place it just below the box.
The following discussion is marked as answered. If you have a new comment, place it just below the box.
The information for Charles Hall states in 2005 he was involved in a car accident caused by a drunk driver. I am the mother of Matthew that was killed in this accident and I would be happy to provide evidence from the inquest that Matthew had not had a drink at all. The alcohol that showed up in one of the samples contained bacteria from Matthews stomach contents due to him suffering crush injuries to his chest. --Meer2005 (talk) 20:39, 26 August 2013 (UTC)
This page is for comments on VisualEditor, our new editing interface. For feedback on a specific article, please refer to that article's talk page. --Cryptic C62 · Talk20:53, 26 August 2013 (UTC)
Just over a week ago, I helped out at an edit-a-thon at the Royal Ontario Museum. Whilst there, I did talk to the new users about trying out VisualEditor (as opposed to the wikitext editor). To a person, they all said that VE was *more* difficult to use than wikitext, especially with respect to references. Now, they had all had reinforced to them the importance of referencing factual information, so they were all trying to include references. They pointed out that at least with the wikitext editor, they could pull up templates that were complete and they didn't have to try to figure out the parameters. They were using mostly printed sources, not websites, so there was no URL to use as a quick-and-dirty reference insertion. The wifi wasn't great there, and even I had a hard time opening pages with VE as compared to wikitext (it kept hanging on me). Finally, they complained that the help pages weren't as helpful as they expected because they were now oriented toward VE, while they were working with wikitext. That last point tells me that we need two complete sets of help pages. Risker (talk) 02:08, 27 August 2013 (UTC)
Real life experience is particularly useful - thanks for this report. My take-away (besides agreeing with you that parallel help pages are needed) is that VE should have something like Wikipedia:RefToolbar/2.0 added, for references. This actually isn't that difficult, programming-wise (at least, it isn't difficult for the four default templates):
Set up a place on the editing menu (perhaps a second line) where the pull-down menu for reference cite templates
Provide an option for each language Wikipedia to indicate whether to display or not display the pull-down menu (default= "no")
Set the label so that it can be specified by each language Wikipedia
Set up a place where each language Wikipedia can specify the templates to be included on the pull-down list
Modify the template/transclusion dialog so that it can be invoked with a new template already selected for it.
The other thing that would help would be a significant redesign of the template/transclusion dialog, to address the existing, significant problems with the user interface/user experience. A lot of the process is far less intuitive than it could be. -- John Broughton(♫♫)03:07, 27 August 2013 (UTC)
Thanks for this, John. I forgot one other very significant point: not a one of them understood what the "puzzle piece" was supposed to represent, and when shown, all of them still thought it was a poorly chosen icon. Most had no suggestion as to an alternative, although two thought "curly brackets" would be a good idea. I suspect that's because they'd seen curly brackets for templates when using wikitext. Risker (talk) 03:12, 27 August 2013 (UTC)
Thanks for your comments.
Do you have the links to the help pages they were using? Most of them say nothing at all about VisualEditor except for a warning at the top, but I believe the pages oriented towards new users have been changing recently. Whatamidoing (WMF) (talk) 03:42, 27 August 2013 (UTC)
The help page comment should be easy to implement - just copy a pre-VE version of each help page to the corresponding Wikitext help page and update some links. VQuakr (talk) 05:46, 27 August 2013 (UTC)
I've added your comments about reference editing to T52458 and reported your comments about the icon for inserting templates as T55396. Thryduulf (talk)
Why are we still using this?
A couple months have gone by since the release of Visual editor and eventhough a large number of problems have been fixed, there are still hundreds of bugs nad enhancements needed. With all the problems that have been identified, and as fast as that list is growing, along with all the limitations and exceptions to using this app, why are still forcing it to be used? We need to stop forcing this out. This application needs to be opt in only for now. Once the major bugs are worked out and we can trust the application to make an edit without screwing it up, then we can make it opt out. The RFC to make this opt in has overwhelming support so its time for the WMF to do the right thing. We need to take a step back, make the app opt in only and not encourage new editors to try and use it yet. We need to fix the bugs and increase the functionality. We need to do these things because its the right thing to do. Hate me if you want for continuing to call attention to this but the bottom line is this application is largely a failure and it needs to be fixed. Kumioko (talk) 14:38, 21 August 2013 (UTC)
Definitely not a fan of "hating" people. As I did before, I'd just remark this is not the right place for similar discussions. For example I can see a similar one ongoing here, which you edited as well, and this specific page has a very different purpose. This said I'd be really glad to help you with specific issues, if you have any. --Elitre (WMF) (talk) 15:10, 21 August 2013 (UTC)
Yeah it seems like there is no good place for this type of discussion. Thanks for the offer but I stopped using the application or submitting feedback about problems after the problems we were identifying and the feedback we were providing were being ignored. But it still annoys me how many problems are allowed to litter the articles without being fixed. VE continues to have problems with adding templates and I have a list of more than a dozen articles that have yet to be fixed. I have 5 that have a broken table, several more that have image problems, etc. I fixed a lot of others but I am sort of using these as a control group to see if the WMF is going to fix the mess they created or rely on the community to do it. I also stopped fixing the problems since the WMF seems intent on using Wikipedia as a petri dish to test and doesn't seem to mind that the application is breaking articles. When the WMF starts to act like they care more about the project than about testing broken software, then I will fix the problems and continue to support the process. I think a lot of others would too. We realize that creating this software is not a trivial thing and problems are going to occur, but we shouldn't be moving full speed ahead knowing that we are leaving a wake of destruction in our rear view mirror. Kumioko (talk) 16:17, 21 August 2013 (UTC)
I think in the case of the French wiki the problems go beyond VE. IMO, that shows that not only is Visual editor problematic but the underlying Parsoid and Universal translator apps need serious refinements as well. All three of these work closely (but apparently not closely enough) but they all tie to VE. Again and as I inferred above. Its perfectly fine if we want to keep testing and developing this and we should. But this should absolutely not be available to IP's and new users yet and it should only apply to users who want to opt in to using it. Kumioko (talk) 18:26, 21 August 2013 (UTC)
In some defense, work is in progress to fix the bugs, but it is unreasonable to expect a bug to be fixed immediately. To give an indication of the scale of the task the developers have for Visual Editor there are 319 new bugs, 411 bugs which have been assigned to someone, 9 with a patch to be implemented so should soon be fixed, and 721 have been fixed. Its going to take a lot of time to fix all those, even going through the new bug to work out if they are real bugs or duplicates of others takes a significant amount of time.--Salix (talk): 21:46, 21 August 2013 (UTC)
@Whatamidoing, Yeah that's it sorry and I was under the impression that was what helped translate from one language to another for things like Visual Editor so that the WMF wouldn't have to make a separate VE app for every single language. Maybe I am wrong. That is very possible.
@Salix, your right and no one, not even me is saying that we expect these bugs to be fixed immediately and no one is saying there shouldn't be any bugs, because that is inevitable with any software application no matter how mature it is. There have been a lot of improvements but the volume o bugs identified in the last couple months alone show it wasn't ready for release. Let alone to new users and IP's. What I am saying is that it should not be pushed to the new users and IP when it has a lot of major problems. Like deleting content, adding things it shouldn't add, breaking tables, etc. These are the kinds of problems that should have caused the WMF to unrelease it and keep it in a beta, opt in status until they were fixed. What's worse, the WMF has absolutely no plan to clean up the hundreds of articles broken by the app. They expect the community of volunteers to do it while disregarding any of our comments other than pats on the back telling them what a wonderful job they are doing and identifying problems with the application that anyone can see was not even close to being release worthy. That isn't even taking into account that several of the most widely used internet browsers isn't even supported. They can't even get it to work. Kumioko (talk) 23:10, 21 August 2013 (UTC)
They don't make separate software for each language. They just make a separate file for each label. If the label is "vector-view-view", then whatever you put in the file "vector-view-view" will show up in that spot. (Have a look at the label names: [23].) It's the same system that allowed us to switch between "Talk" and "Discussion" tabs a few years ago, and to change "Edit" to "Edit beta" three weeks ago. What the ULS does is—if you've set some other language—show you the labels from the same kinds of files, but using a different group of files. ULS needs some performance work, but the actual process of showing "Página" instead of "Article" requires no extra work. Whatamidoing (WMF) (talk) 02:37, 22 August 2013 (UTC)
@Salix: I do understand that it will take time to fix the bugs, and I also find that normal and expected. The only thing I don't understand is why VE hasn't been rolled back to opt-in by WMF when it's obvious that it will take time to fix the bugs and have an editor that is not damaging hundreds of articles every day. Especially since WMF has decided that it's not their task to fix the articles damaged by VE, but volunteers who are repeatedly asking to go back to opt-in mode... --NicoV(Talk on frwiki)05:13, 22 August 2013 (UTC)
@User:NicoV, not sure you saw that Ssastry took care of the problem you linked here, it's here now, and it's a Parsoid bug - it appeared on it.wp as well, and it's useful for others to know it is duplicating parts of the article. --Elitre (WMF) (talk) 17:20, 23 August 2013 (UTC)
Thanks, but not sure this bug has anything to do with the problem I linked, and the problem I linked was in fact 3 problems: nowiki at the beginning of a line, nowiki inside internal links with no text ([[Alésia|<nowiki/>]][[Alésia|<nowiki/>]][[Siège d'Alesia |<nowiki/>]][[Siège d'Alésia|Alésia]]), strange internal links ([[Commentaires sur la Guerre des Gaules|Commentaires]] [[de]] [[César]] [[sur]] [[la]] [[guerre]] [[des]] [[gaules]]). And the only answer I got on frwiki is still that "nothing proves it has anything to do with VE". --NicoV(Talk on frwiki)18:47, 23 August 2013 (UTC)
The nowiki tags at the start of the line (<nowiki> </nowiki>Il prit la voie directe allant de Langres à Lausanne...) are a known bug that was fixed in the most recent release (reached frwiki late on Tuesday).
The Alésia mess (...une citadelle religieuse celtique, [[Alésia|<nowiki/>]][[Alésia|<nowiki/>]][[Siège d'Alesia |<nowiki/>]][[Siège d'Alésia|Alésia]]. is T39835.
The multiple link mess ([[Commentaires sur la Guerre des Gaules|Commentaires]] [[de]] [[César]] [[sur]] [[la]] [[guerre]] [[des]] [[gaules]] is probably a consequence of fixing the bug that made anything you typed after a link become part of the link. I'm not sure what do with it. It would be very helpful to know exactly how this series of links was created. Whatamidoing (WMF) (talk) 19:28, 24 August 2013 (UTC)
Well, to know exactly how the problem was created would require to ask the user and that he knows how he did it, but he probably won't because I don't think he ever signed up to be a beta tester. But you can ask him.
Can I also ask why no WMF liaison is answering on the frwiki feedback page now that VE has been forced on every user ? Users are reporting problems there, but their reports seem to be simply ignored. --NicoV(Talk on frwiki)10:59, 25 August 2013 (UTC)
NicoV, sorry for the confusion about the bug :) I just assumed Ssastry and I were talking about the same thing. For the user thing, that's exactly the way to tell it was really VE to cause the mess - and is what I often do, even with experienced users (your user joined just recently). As for the liaisons, both here and on it.wp i.e. you can see that now mostly users help each other because this is how it should work in the long term. It should be also worth noticing that here and elsewhere it's written All comments are read, but personal replies are not guaranteed. As most of the liaisons are increasingly working now on preparing new wikis for deployment, please feel free to ping any of us in case of bugs which are not already known and reported on Bugzilla. Thanks! --Elitre (WMF) (talk) 11:30, 25 August 2013 (UTC)
Hi Elitre. Your answer worries me... In the long term users will help each other, yes sure, but VE has been deployed recently and it's still full of bugs, some of them still damaging articles. So, honestly, when I read that liaisons are preparing new wikis for deployment, instead of managing the feedback on the already deployed wiki, when everything clearly shows that VE is still not ready: I can only think that VE team is still not listening to users and still doesn't care about damages made by VE on wikipedia. What is the point in deploying more when you know that many damaging bugs are still present, and that you don't even manage to handle the current flow of feedback ? --NicoV(Talk on frwiki)13:33, 25 August 2013 (UTC)
NicoV, there is no need to worry. We can definitely keep supporting and keep deploying. If both staffers and volunteers did not care, bugs would not be reported to Bugzilla anymore, which is definitely not the case... No need to overreact, especially since the flow of feedback is actually quite low now when compared to the first deployment days (and I can see some volunteers at work on fr.wp as well, as a matter of fact), and no direct answers, wherever they happen, should definitely not imply "the flow" isn't being handled. --Elitre (WMF) (talk) 14:14, 25 August 2013 (UTC)
I agree with Nico and there is absolutely a need to worry. The RFC shows almost 500 editors are worried. The ongoing cavalier attitude from the WMF and its staff about the damage done to the project are worrisome and irritating to those of us that volunteer our time to help build it. VE still causes too many problems, there are still problems lying around that haven't been fixed and it doesn't work with IE which is one of the most widely used browsers. Once they do get it to work with IE I think we can all assume there will be more errors with it that will need to be addressed. At this point, not pulling the software back and stopping deployment is just negligent and shows the WMF doesn't care about the community or the project. We are just number to the WMF. Kumioko (talk) 14:19, 25 August 2013 (UTC)
By not handling the flow, I meant not handling fixing the flow of feedback: there are currently 777 open bugs for VE in bugzilla (for 735 fixed from the beginning of VE), this number is still increasing. Yes, the flow of feedback is quite low: still people on holidays, and many people are still waiting to see bugs reported a month or two fixed. --NicoV(Talk on frwiki)14:34, 25 August 2013 (UTC)
I would also add that the flow of feedback has also decreased because most of us know that the WMF isn't listening, so why bother. The flow of discussion has decreased because people aren't even trying to use the application and have given up on it, because its crap. Kumioko (talk) 15:55, 25 August 2013 (UTC)
The people who are using it are not the ones who are leaving comments. These are new and casual users who are editing with the assumption that the application works and are generally unaware that the application causes errors. They assume, and rightly so that the application should work. And the number of usage are down from when it was first released. Kumioko (talk) 16:17, 25 August 2013 (UTC)
I believe the drop in usage about a month ago coincides with a change in labelling the link for VE, from "Edit" to "Edit beta"; perhaps someone else can confirm that. Other than that I don't see a significant change in usage. Mike Christie (talk - contribs - library) 16:26, 25 August 2013 (UTC)
Yes, it does. Rearranging the tabs ("Edit source" is first and therefore most convenient) probably had a bigger effect on reducing use. I believe that the changes resulted in an immediate drop of something like 25%. Whatamidoing (WMF) (talk) 22:07, 25 August 2013 (UTC)
I agree that was probably part of it but I believe that a significant reason is because we let them know it was a beta release of the app and not ready for prime time. In my experience a lot of people won't use something that says beta. Kumioko (talk) 23:46, 25 August 2013 (UTC)
Nico, you do have a WMF staffer at the frwiki feedback page. He's just one of the many staffers who prefers to use an account name without "(WMF)" at the end. Whatamidoing (WMF) (talk) 22:07, 25 August 2013 (UTC)
What's the point in the stats ? I don't deny that there was many posts from WMF on the entire lifetime of the feedback, I was just saying that we had almost no more answers now that VE has been turned to opt-out on frwiki. If you look at the history, you will see that, except for the batch of answers that happened today (only after I have reported here several times), there was no real answer in the last 3 weeks... That's what I was reporting: the official reason for deploying on more wikis was to get more feedback, but on frwiki I felt that our feedback was simply ignored. --NicoV(Talk on frwiki)16:52, 27 August 2013 (UTC)
Be assured, it wasn't. As a matter of fact, since our dear Guillaume is not "technically" a liaison for VE, I'll guess that I will be soon helping him actively there. There, this is what you get when you complain too much! ;) --Elitre (WMF) (talk) 17:17, 27 August 2013 (UTC)
VE + ULS unicode Devnagari Script input issues
Hi,
With reference to bug no 49569. From my todays test edits at mr wiki, it seems some efforts have taken place to initiate/enable ULS unicode Devnagari Script input in VE edits.But for practical usage,even for primary begining, it seems to have too many issues yet.Before informing the issues do we wait untill we are officially informed from your side or do we start reporting issues ?
I suppose till now there is no separate bug to track "VE+ULS unicode Marathi language Devnagari script issues". Would you prefer to start a separate bug for tracking or you expect us to join with some existing bug reports for related issues.
Hey Mahitgar, Elitre. As VE will not be usable on wikis where ULS isn't integrating properly, I'd be filing this as a VE bug, and as a "blocker" to Marathi deployment depending on severity. It is fine to file as a separate bug - if the devs discover it is linked to another reported issue already assigned, they can merge the reports. Mahitgar, can you give us a more detailed report about the specific issues you are noticing on mr.wiki, as well as the browser and operating system of your computer? With that, we can submit a actionable bug report, and work to get this fixed before any rollout to Marathi. Can't offer much insight to this particular script - I haven't been working with the Indic languages - Jan and his team are working on this. User:JEissfeldt (WMF) - tag, you're it! PEarley (WMF) (talk) 16:33, 23 August 2013 (UTC)
Thanks, I have the CIS in Bangalore putting together a file on critical bugs for Indian language versions for this product since yesterday and will expand it as necessary. This looks like a solid candidate to me, regards --Jan (WMF) (talk) 18:00, 27 August 2013 (UTC)
Thanks for all above replies.I will study and list problems for Marathi language VE+ULS environment here in a tabular form over couple days
In normal speed typing,after we type first alphaabate cursor moves from right to left direction.Word marathi need to apear मराठी with VE+ULS instead is coming राठीम
Marathi language devanagari is written in left to right direction.But when we use ULS Method of input = अक्षरांतरण with VE cursor is moving in opposite direction as if we are typing a right to left script
I did not see this mentioned elsewhere, but I have encountered a bug where, if I add multiple citations to back a statement, the Visual Editor only saves the first citation I added. This happened once when I added three citations to back a claim and had to add each one individually over the course of three edits and again just now when I had to add a second citation after it didn't get saved. Multiple citations can be added if they are separate as I had added a citation for another statement in the same edit and it was saved. Seems VE has a problem specifically with citations being added next to each other.--The Devil's Advocatetlk.cntrb.00:39, 27 August 2013 (UTC)
Hi there! If you want to reuse a reference, make sure you follow these steps (just remember that, right now, you need to save first before being able to use a new reference). Does this help? Thanks, --Elitre (WMF) (talk) 10:01, 27 August 2013 (UTC)
VisualEditor does not currently support adding reference names, but this is requested at T52568. Unfortunately that bug has remained unprioritised since it was reported in early July so I can't say when the feature is likely to be added. Thryduulf (talk) 10:19, 27 August 2013 (UTC)
The article The Legend of Korra (Book 2) gets constantly disrupted when somebody edits (any part of) it using VE. The following two lines of text are inserted into a table:
<ref name="Futon">{{ns. -->
|''''=|ok Tw=| Spir=ts''''' is the second season of the animated TV|ser=es ''[[The Legend of Korra]]'' by [[Michael Dante DiMartino]] an| [[B=|an Konietz=}}</ref><ref name="Futon">{{ episode| ("c=|pters=|. Ord=red in early 2011, ''Book Two: Spirits'' will a|r o= [[Nickelodeon]] in the U.S. beginning on September 13, 2013.<re| nam=|"Yahoo 15 =}}</ref><ref name="Futon" /><ref name="Futon" /><ref name="Futon" /><ref name="Futon" /><ref name="Futon" /><ref name="Futon" /><ref name="Futon" /><ref name="Futon" />
Please check the recent article history. Although at first I though this was some persistent vandalism, I seriously doubt this now. If possible, please edit the article in such a way that the bug does not show up any more. YLSS (talk) 06:59, 27 August 2013 (UTC)
This is usually caused by some minor error in the table markup such as a missing quote, but I've not been able to find anything. There are other people far better at spotting those things than I am though, so hopefully someone will notice something I haven't. If this is the cause then it is T51839. Thryduulf (talk) 10:44, 27 August 2013 (UTC)
Did some testing in a sandbox out of curiosity. The error is caused by the named ref "Futon" in the table, and only when it is formatted as a named ref:
Moved the ref as named ref outside of the table structure and deleted all iterations - OK, VE works.
Used exactly the same cite within the table, but only as unnamed, single "ref" - OK, VE works.
Removed all references from table and added a new named ref "TEST" within the table - VE-edits get corrupted with "TEST"-text. GermanJoe (talk) 11:57, 27 August 2013 (UTC)
This one [[27]] is an article version, that is OK for VE. I have reverted back to the original situation: [[28]] (VE error). Something in the difference is the cause :). GermanJoe (talk) 12:44, 27 August 2013 (UTC)
Indeed, but I haven't yet figured out what that something is! I can't reproduce it in a simple table with that reference in my sandbox [29], so it seems likely to be the interaction between named references and something else. I haven't got time at the moment to investigate further. I've reported it as T55402, but it can be refined if we can narrow it down. Thryduulf (talk) 14:15, 27 August 2013 (UTC)
VE doesn't accept ref names with leading and ending quotations marks in this specific situation. Changed the OPs article to fix that for now, but it's definately a bug. GermanJoe :(talk) 14:22, 27 August 2013 (UTC)
you can see that the td-cell produced by the template will break. So, the template is not designed to take anything but numbers/strings for the ProdCode parameter. The same is true for the EpisodeNumber parameter. All uses of this template in WP pages where these parameters are not strings are errors in source wikitext on those pages. Hope this clarifies the matter. Ssastry (talk) 16:01, 27 August 2013 (UTC)
I've been trying to figure out how this was done. You can't add a named ref at the moment, so it must have begin by re-using (and modifying) an existing one. But then why did it add a second/different instance with the same name, rather than changing the original? Whatamidoing (WMF) (talk) 15:19, 27 August 2013 (UTC)
This bug affects all edits in VE, whether you touch the table or references or not, so the inability to name references in VE is not relevant here. As for adding references with the same name, do you mean something like T54755?
Anyway Ssastry has commented on the bug, saying that it's some sort of interaction problem with something the episode list template does. I don't understand it, but those who understand template coding are encouraged to read T55402 (comment #1) and see if they can fix the problem. Thryduulf (talk) 16:02, 27 August 2013 (UTC)
Yes thanks. Our posts were almost simultaneous, but I didn't get an edit conflict so I hadn't spotted it until I saw my notification flag. Thryduulf (talk) 18:14, 27 August 2013 (UTC)
mistranslation
The following discussion is marked as answered. If you have a new comment, place it just below the box.
there is a mistranslation in the Etymology section of this article. Nishikigoi translates literally as Western (Nishi-Ki) Carp (Goi/Koi). 98.65.239.24 (talk) 15:51, 27 August 2013 (UTC)
This page is for feedback about the visual editor. to give feedback about a specific article you should post on that article's talk page. Thryduulf (talk) 16:04, 27 August 2013 (UTC)
Mysterious attempt to use anchor element
I've just found this edit; see the first two changes where the <a>...</a> element has been used. this element is not permitted in wikitext - was it added by the user, or by VE? --Redrose64 (talk) 16:14, 27 August 2013 (UTC)
Yes, this seems to be a bug in Safari on the iPad where it "helpfully" converts numbers in certain editing areas that it thinks are phone numbers into external links that phone applications understand. The VisualEditor editing surface is one such text area but it is not limited to VE (and there are similar problems with some other browser plugins). The devs though are trying to work out a way to detect these injections and stop them getting into the saved revision. Thryduulf (talk) 16:45, 27 August 2013 (UTC)
Can't access the album review section
In album articles (like Def Leppard's X) I can't edit the reviews section because the track listing is next to it. Please fix this. Mab987 (talk) 05:50, 27 August 2013 (UTC)
I forget which Bugzilla number this is, but the problem with editing X (Def Leppard album) is that the article is formatted with multiple columns, another basic fundamental feature of Wikipedia editing that was neglected in the rush to release VE.—Kww(talk) 06:24, 27 August 2013 (UTC)
I can not figure out how to return to editing the article when using the "Edit" (rather than "Edit Source") option. In order to preview changes, it appears that I need to click on Save page. From there I can preview the changes, cancel, or accept--but I cannot figure out how to return to the edit form and change my changes rather than discarding all of them (or accepting all of them). Am I missing something, or does the "Edit" functionality not include that feature yet? Grim0098 (talk) 02:30, 28 August 2013 (UTC)
You might want to check Template:Disable_VE_top out which might be a useful workaround if applied to those sections - we can then remove it once the bug is fixed, as in the case of some airport tables. Looking into the bug now. --Elitre (WMF) (talk) 07:06, 28 August 2013 (UTC)
Here you can see that a random edit when the tables are "shielded" with those template does not cause any harm. Anyway, it's weird because here you can see that a similar edit did not cause any trouble either when the page was basically featuring almost only the very same tables. It does take a while to load and edit the article with VE, though. --Elitre (WMF) (talk) 08:32, 28 August 2013 (UTC)
I have reported this as T55468. I can see no logical reason why the first edit to the table worked and then the next edit caused a monumental cockup. Thryduulf (talk) 11:23, 28 August 2013 (UTC)
In {{For}} the fourth parameter can't be added without the third
Hmm, this will need an extension to TemplateData so that parameters can be defined as requiring another parameter. T52407 is a request to be able to define exactly this sort of dependency relationship, although there appears to have been no full understanding of the need for it by the dev who commented and there has been no activity since July. Unfortunately I don't expect that VE will be able to do anything about this until it can be expressed in TemplateData as that is the only way that VE knows anything about parameters. I've filed the VE request as T55469 though so it can be worked out when TemplateData is extended. Thryduulf (talk) 11:47, 28 August 2013 (UTC)
e.c. I am not sure this is a bug. The template is probably meant to work like this, i.e., if you don't provide the third, you shouldn't add the fourth ;) I think you can already make this clear in the description/label fields of the related TemplateData: this would prevent people to do the same and hence avoid the problem. --Elitre (WMF) (talk) 11:53, 28 August 2013 (UTC)
Of course: and you can "skip" parameters with VE as well, but I guess only in positions where you are allowed to do so, not where the template expects to find a sequence. And you can definitely warn against this with TemplateData already. (I haven't experimented with other templates though). --Elitre (WMF) (talk) 12:27, 28 August 2013 (UTC)
The problem seems to stem from the fact that that table is poorly formed, it has </tr> tags, but no corresponding <tr> tags. It still shouldn't mangle the table, but at least it should be a rare thing to encounter. My sandbox testing shows that there appears to be no issues with HTML tables more generally.
Nice work. At some point you may want to add LaTeX editing (probably best to do raw, not WYSIWYG LaTeX!). Also, when I clicked the Edit button it added a new line between the title and the first paragraph that I couldn't remove. 86.184.25.131 (talk) 11:16, 28 August 2013 (UTC)
When reading an article or editing it using the standard editor, redirects appear as green links instead of blue since I configured it that way. VE does not seem to use these values, and shows all internal links (including red links) as blue. 28bytes (talk) 11:37, 28 August 2013 (UTC)
Yes, this is an often requested feature tracked as T39901. It doesn't presently have a target for when they expect to fix it though, sorry. Thryduulf (talk) 12:00, 28 August 2013 (UTC)
Editing infoboxes using VE (as I did here) is somewhat difficult and unintuitive. I just wanted to change an uppercase "T" to a lowercase "t", but instead of just clicking and editing the desired infobox text, you must click on the infobox, then click the "transclusion" puzzle piece, then find the parameter that contains the text you wish to edit, and then edit the wikitext (not WYSIWYG text) as desired. While there are a wide variety of infobox types, some sort of WYSIWIG editor for them would be extremely helpful. 28bytes (talk) 11:48, 28 August 2013 (UTC)
I tried to create my first VE article today (I've created 100 or so the "old fashioned" way.) Here are some observations.
How does one create a redirect in VE? There does not seem to be an obvious way to do that.
When adding references, a plain box is presented. It's not obvious that to use one of the common {{Cite}} templates, you have to click the "add transclusion" button, and then manually type in the citation template you want. There should be some sort of menu to let you pick from the most frequently used citation templates.
When adding "The New York Times" as the "newspaper" parameter, I wanted to link to The New York Times but it was not obvious how to do so. Ctrl-K does not work in that box.
When adding the first reference to an article, VE should add a == References == section with {{Reflist}}. Or at the very least, just {{Reflist}}. As it is, the reference is just "hidden" when you enter it, and it's unreasonable to assume a new user will know they have to click the "transclusion" button and manually type in "Reflist" to get the references they entered to appear. There is no warning that the {{Reflist}} is missing until you actually save the article, when you get a scary red message at the bottom.
Adding: this seems to be a common problem among the other VE article creations today: [32][33][34]
Clicking on a link during preview mode doesn't work right: I used the hyperlink button to create a link to Salvation Army, but when I right-clicked on it and chose "Open Link in New Tab" (I'm using Firefox 23), I got this page.
How does one add categories? There does not seem to be an obvious way to do that.
Why does the "style" box contain a "Page Title" option? It is my understanding that level 1 headers are not supposed to be used in articles.
There seems to be an odd caching issue: whenever I try to link to the newly created article from another article, it does not auto-fill and says "new article" with a red link when I type it manually.
This looks the typical case where I prepare a very long answer, only to find out User:Thryduulf already got it - and better than me. So, pinging him to find out whether this is what would happen. In the meantime, thanks for your report. Almost everything looks already known to me, luckily :) and some answers can already be found in the user guide or in the known problems page. --Elitre (WMF) (talk) 14:08, 28 August 2013 (UTC)
Yes, it's still doing it, for me at least: I created the redirect home for unwed mothers this morning, and every time I try to link a page to that, VE says it's a red link. Perhaps you can try one of the articles that has it unlinked (Wickliffe, Ohio is the next one on my list) and see if you get the same results, or if it's just me? Incidentally, trying to link it on Reunited (TV series) generates some odd behavior: if you use Firefox, press Ctrl-F and then type in the text "home for unwed mothers" (without the quotes), that text will be highlighted, but if you then press Ctrl-K, the == References == heading is what gets blue-linked. (I suspect this is due to the way it handles templates, since the found text appears to be embedded in one.) 28bytes (talk) 18:48, 28 August 2013 (UTC)
Hi 28bytes, I tried it just now, and it's still not working for me like it ought to. It makes the link, but the link inspector does not believe that the page exists. I also found this on a page (Odd) that is clearly not new, although most of the older pages work correctly for me. It doesn't matter if the capitalization is upper or lower for the leading character, and it also doesn't matter whether I type the word first or enter the link inspector first.
I also found a new problem, which is that if you select a word, enter the link inspector, and then cancel (escape key or "<" button), it links the word to the first thing in the search list anyway. Is anyone else getting this? I'm using Safari 6.0.5 on Mac OS X 10.7.5. What are you using? Whatamidoing (WMF) (talk) 17:14, 29 August 2013 (UTC)
Firefox 23.0.1 on Windows 7. (Happens on Vista and Windows 8 too, FWIW.) Yes, I have noticed that when you cancel from the link dialog it will create a link anyway, and you have to Ctrl-Z to undo it. 28bytes (talk) 17:33, 29 August 2013 (UTC)
That's enough of a mismatch that it's probably all browsers and all OSes. I've added T55546 for the 'since when did Escape mean Okay?' problem.
The problem with the redirects appears to be T51502: they're deliberately filtering them out. (I supposed that if you're trying to link to Cancer, that you don't really want to see a list of the dozens of pages that redirect there.) But Odd isn't a redirect, and other disambiguation pages work correcltly. So the new not-a-red-link bug is T55547. Whatamidoing (WMF) (talk) 18:23, 29 August 2013 (UTC)
Also
Thanks. The user guide answered my question about categories, but raised a few more:
What is the "reference list" button supposed to do? I clicked on it while editing maternity home and a blank dialog came up; I was expecting a list of references (just one reference at the moment.)
In that same article, is there a reason VE will not let me use the uncapitalized link "pregnancy" but forces it to uppercase?
Similar to the request to make infoboxes directly editable, it would be nice to make references directly editable as well. For example, I tried clicking on the "The New York Times" in the reference so that I could link it, but could not do so; I had to click the [1] in the section above, then the reference icon, then the cite template, then the transclusion icon, then the "newspaper" parameter, then I manually added brackets and clicked "apply changes" first at the transclusion level, and again at the reference level. And at that point, the changes did not appear to be applied; "The New York Times" still appeared unlinked. I had to save the page and then reload it to make sure the linking worked. That's a lot of clicks just to link something! Using the wikitext editor that would be two clicks; highlight "The New York Times" then click the "[[]]" toolbar button; so this could definitely be streamlined in VE, I think, to make life easier on newer editors. (And older ones too, I suppose.)
It adds <references />, and nothing else. Just choose "apply changes" and it works. (Some instructions on that nearly blank box would be helpful.)
T52452. The workaround is to first type pregnancy, then select it, and press Control+k to enter the link inspector. If you press Control+k first, and then type pregnancy, the autocomplete "feature" gives you leading caps.
I couldn't find anything about the wrong URL on right-clicking, so I added T55491. I didn't have any success in reproducing it in the mainspace, but I got two different wrong URLs from my sandbox. Whatamidoing (WMF) (talk) 18:43, 28 August 2013 (UTC)
OK, thanks. I am able to reproduce T55491 consistently; I just start a new article, and any links I create and right-click on generate the 404 error. 28bytes (talk) 18:53, 28 August 2013 (UTC)
What about a dialog after inserting the first reference ? "There is no references list in this page yet. Do you want to add one now ?" —TheDJ (talk • contribs) 18:55, 28 August 2013 (UTC)
Sorry I wasn't around earlier, I was showing my face at the WMUK office! I've marked bug 53491 (wrong link target) as a duplicate of T50915 although as that bug's title "VisualEditor: Respect Parsoid's <base>" describes the solution not the effect so I'm not surprised you didn't find it (I only found it when a bug I reported was marked as a duplicate of it).
There are several issues with links, and the workaround for all of them is to write the text of the link first, select it and then link it. I've reported this specific issue as T56395 recommending that the first character of the string input should be preserved, i.e. if you enter "Green" you get Green, if you enter "green" you get green. T50789 should make all this easier, as that asks for a way to explicitly set the display text from with the dialog.
T53864 relates to the paragraph styles drop-down, asking for individual options to be enabled/disabled on a per wiki per namespace basis. This is a low priority request though as its a nice to have rather than something essential.
VisualEditor stopped working completely like a month ago
My VisualEditor stopped working completely like a month ago. When I try to edit, the article's text goes gray, and the "loading bar" appears and shows does the loading animation. But that's it. It never loads. I am using Fireox 22.0 (technically Iceweasel). I have deleted my browser cache completely. I even tried resetting my Wikipedia preferences but it still happens. Any ideas? Cookies and Javascript are enabled too. Jason Quinn (talk) 01:42, 29 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
In Australia, 'bok choy' is also used. Source: I've lived in Australia my entire life, and I'd only ever heard 'bok choy' until I read this article. Not sure if that's a valid enough source, though I thought I might at least mention it. 202.61.150.40 (talk) 12:29, 29 August 2013 (UTC)
This page is for feedback about the VisualEditor. For feedback regarding a specific article, please use that article's talk page. Thryduulf (talk) 12:39, 29 August 2013 (UTC)
Sham entry
The following discussion is marked as answered. If you have a new comment, place it just below the box.
This entry is religious propaganda. It is opinionated, unreferenced and a promotion for this person. See Wikipedia entry for "Daniel Nalliah", his co-founder of their evangelical church. 123.2.188.143 (talk) 14:22, 29 August 2013 (UTC)
This page is for feedback about the VisualEditor. For feedback regarding a specific article, please use that article's talk page. GermanJoe (talk) 14:29, 29 August 2013 (UTC)
Easier to use
I just discovered something that is much easier and faster to do in VisualEditor than in the classic editor: fixing list formatting. Someone had made a list of books without any list formatting. Each "list entry" was a paragraph, separated by blank lines. Fixing it required only highlighting the list and clicking the list button. All the blank lines were automagically removed. I'm very happy about this. WhatamIdoing (talk) 15:20, 29 August 2013 (UTC)
Hi,
When trying to link to other wiki pages, most of the time the correct page shows up but when it doesn't there is no way to create a new link. For instance, I'm trying to link "Me and My Chauffeur Blues" from the Memphis Minnie list of songs page to the "My Chauffeur Blues" wikipedia page. BIcurious3334 (talk) 15:23, 29 August 2013 (UTC)
The article you are trying to link to is at Chauffeur Blues, although I'll create a redirect from the title you were using in a moment. You can always enter a link to a page that isn't in the list though, just type out the name in full and press enter or click the red linked top entry in the list. Thryduulf (talk) 16:20, 29 August 2013 (UTC)
Using Firefox 23.0.1 in Windows XP, if I view W. S. Gilbert, whether logged in or not, most images are 220px wide. This is because they use the thumb parameter, and 220px is the default on English Wikipedia, and what I have not changed my preferences.
For reference the edit in question is [36]. I'm not sure whether what you describe is desired or not and if it isn't what would be better? Thryduulf (talk) 22:36, 29 August 2013 (UTC)
Not related to this problem as such, but I've reported the <nowiki> added in that diff as T55571. It seems to be triggered by single apostrophes following links in a bold or italic section. Thryduulf (talk) 23:32, 29 August 2013 (UTC)
A point was raised yesterday about an editor who was continually making changes to articles contrary to comments in the wikisource (two examples of such comments being "<!-- DO NOT CHANGE THIS NATIONALITY WITHOUT DISCUSSION ON TALK PAGE -->" and "<!-- This is, as Wikipedia guidelines suggest, as he self-identifies and by long-term consensus -->" ). A suggestion was made that as the editor concerned was using the Visual Editor he would not have seen these comments in the source. Is this true? (I don't use VE, and I'm an IE user so couldn't use it if I wanted to, so can't check). - David Biddulph (talk) 18:27, 28 August 2013 (UTC)
Yes, that is true. The FAQ, on this page, uses this problem as an example (search for "hidden comments", on this page, above). You might think that being in the FAQ, as an example of a common problem, would make fixing this a high priority for the developers. If so, you'd be wrong.
As an aside, "fixing this" is as simple as making text within hidden comments visible but non-editable (and in a different font - for example, white on a black background). That's not perfect (it would be good to be able to edit such comments), but that would be good enough for the moment - and, quite frankly, it seems not-all-that-difficult, programming-wise. -- John Broughton(♫♫)20:32, 28 August 2013 (UTC)
My programming is limited to a very small amount of python as well as some HTML and wikimarkup, so I could be wrong but.. Is it really that hard to program in "look for <!-- and then display what's in between as something -->? Potentially, it could be displayed as an inline box or something. That cannot be that hard to code from my limited knowledge. ~Charmlet-talk-22:34, 28 August 2013 (UTC)
My programming knowledge is less than yours, but my guess is that the difficult bit is making sure that by showing this it doesn't break something else. You also have to decide how to show something that wont be seen when you save the page, given that the point of VE is to be basically WYSIWYG (although it can't be completely). Neither of these things should have held it up as long as it has been though, so there may be something that you and I aren't seeing. I've done what I can to bring it to the dev's attention on bugzilla today, but @Jdforrester (WMF): may have more information about its prioritisation past and present. For now though we all just need to be patient. Thryduulf (talk) 23:47, 28 August 2013 (UTC)
(edit conflict) The suggestion was correct, VE users cannot see hidden comments. High priority T51603 is about addressing this issue, and I've copied your comments there to try give it another push. Thryduulf (talk) 20:35, 28 August 2013 (UTC)
I've commented further at bugzilla about programming and user interface issues. Responses/rebuttals are welcome, of course.
I originally was inclined to suggest displaying the hidden text in full, but with a different font/background color. I'm now more inclined to have the person doing the edit see a yellow warning icon (see examples here), and by hovering, to then see the full hidden text. That, to me, seems both less disruptive (the hidden comment is reduced to an icon, so it hardly disturbs the flow of the text, and maintains, roughly, the WYSIWYG concept of VE) and simultaneously harder to ignore - it waves, figuratively, a big flag in front of the person doing the edit, saying "LOOK HERE". -- John Broughton(♫♫)00:26, 29 August 2013 (UTC)
As PamD notes at Bugzilla, the point of these notices is that they need to be front and centre so there is no question that you have seen it. I also understand that hovering is not easy/not possible on touch screen devices. So I don't think that hiding them behind an icon is the best way to do things, unless they are expanded by default and you can click on an icon to get a more WYSIWYG view. Thryduulf (talk) 10:34, 29 August 2013 (UTC)
Yeah, I like this idea: show the comment with a foreground/background different to the editable text, and allow it to be collapsed to confirm a WYSIWYG view.
Hi there, AFAIK the page is archived by a bot. We couldn't really edit here anymore if bugs which are not solved on Bugzilla are not archived. We use sometimes the "answered" template, but any section featuring this template can still be edited, of course. If you'd like to get updates on specific bugs, please add yourself to the CC list for that bug on Bugzilla, so that you get email notifications when the bug is changed: also, if you think that some discussion which is now archived deserves some more attention, just ping people to notify them about updates or new comments, like this: Mark Hurd :) --Elitre (WMF) (talk) 14:12, 30 August 2013 (UTC)
Yeah that was rhetorical, hence the smiley :-) I have added myself to the CC for this bug, which I commented on a week or two ago, and I actually reported the list continuation bug T54399. Thanks for showing me how easy pinging is now though. Mark Hurd (talk) 14:40, 30 August 2013 (UTC)
You are right that the numbers won't match, but the references still work in that they can be correctly edited - you wouldn't be able to preview them by hovering on the number anyway. Adding to [37] though, thanks :) --Elitre (WMF) (talk) 09:53, 29 August 2013 (UTC)
From the bug comments, this was allegedly fixed two releases ago, but I'm seeing the same problem that Davipo reports. VisualEditor finds ten refs in the inforbox, but still starts over with ref #1 in the body of the article. Whatamidoing (WMF) (talk) 17:26, 29 August 2013 (UTC)
This isn't the same as T53289, when that was happening the references for the infobox would not have appeared in the reference list at all, this is just problem with numbering. Thryduulf (talk) 18:45, 29 August 2013 (UTC)
Possibly. I've crosslinked them and given T54300 a more descriptive title (making it easier to find). If I get time tomorrow I'll go through some more of the unconfirmed VE bugs and see if they're still occurring, but it would be really useful if James or someone else on the VE team could reduce the backlog of unassigned bugs and prioritise them. Thryduulf (talk) 22:27, 29 August 2013 (UTC)
Feel free to look at T54478 while you are at it. It truly annoys me to see the VE team brag about responsiveness when they can't even take the time to confirm and prioritise the bugs coming in, especially when I take the time to distill a test case for them to look at.—Kww(talk) 22:42, 29 August 2013 (UTC)
Thanks. Perhaps you can persuade James that deciding that deciding that the {{#tag:ref}} feature never should have been supported in the first place falls outside of his scope.—Kww(talk) 23:53, 29 August 2013 (UTC)
As the subject says -- no means exists of adding this important feature. Additionally, no means exists of flagging this article as containing questionable content. 173.11.86.22 (talk) 18:57, 29 August 2013 (UTC)
(edit conflict) Citation needed can be added. You just need to use the transclusion (AKA template) editor - click on the puzzle piece icon on the toolbar, type "citation needed" into the input box, click add the template, optionally add the reason and/or the date and click apply changes. Thryduulf (talk) 19:15, 29 August 2013 (UTC)
(edit conflict) I've done it. It's, admittedly, a little harder in VE (this'll likely change) but you just click the icon that looks like a puzzle piece, type "cn" when asked which template, and it'll appear when you hit confirm. I believe the VE team intends to have a some one click solutions in the near future, including adding templates of your choice to a bar? Although I'd hope there'd also be a few automatic lists you could choose to pull up - cleanup templates, etc. Adam Cuerden(talk)19:18, 29 August 2013 (UTC)
Those are good ideas Adam, but not ones I've heard before. Did you get that Wikimania or is there a reference to it somewhere? Thryduulf (talk) 19:33, 29 August 2013 (UTC)
I'd thank Adam for the brainstorming: I read this before though - I think this was asked at it.wp before as well. Right now I can't find the related bug, will take a better look tomorrow :) --Elitre (WMF) (talk) 20:02, 29 August 2013 (UTC)
We discussed a customisable template toolbar at Wikimania, but having a few default sets selectable seemed like the logical extention of that. Adam Cuerden(talk)15:26, 30 August 2013 (UTC)
A quick mockup of how my suggestion could look I've left some comments on that bug, including suggestions for quick access buttons to commonly used templates. A crude mockup of how they might look is attached here. Thryduulf (talk) 22:16, 30 August 2013 (UTC)
You can enter subst:prod as "unknown" template name and add it in VE, after saving it will be substituted (disclaimer: i tested this only with subst:prod and subst:nld in my sandbox). It's not really comfortable, but parameters can be added manually as unknown parameters (f.i. the reason for prod). GermanJoe (talk) 08:08, 30 August 2013 (UTC)
How are some people thinking this is a valid place for article feedback? I located this link from the BETA link once I'd started the VE. Is there any other place it is available from? Mark Hurd (talk) 14:21, 30 August 2013 (UTC)
Well, it's available from any VE-related page, via the navbox. I should check the "what links here" though since I was asking myself the same question. I was thinking about some kind of sitenotice I might have hidden, welcoming templates, or new user guides. --Elitre (WMF) (talk) 14:30, 30 August 2013 (UTC)
I've checked what links here and didn't see anything obviously "interesting". I'll spend a few minutes now trying things in an incognito window to see if I can find something while logged out... Mark Hurd (talk) 15:02, 30 August 2013 (UTC)
People using this page for article feedback is T53875 also see [38] which describes why the user interface design actually encourages this behaviour. --Salix (talk): 17:38, 30 August 2013 (UTC)
This isn't an unusual level of wrong-forum posting. The Help Desk gets more misplaced comments. Eventually, I assume that the beta label and the link to this this page will be removed from VisualEditor, which ought to end this minor problem. Whatamidoing (WMF) (talk) 20:58, 30 August 2013 (UTC)
Unable to save edits or review changes while editing
This is likely a transient problem, but wanted to at least squeal "ouch" as I've been unable to review changes or save changes via Visual Editor over the past 30 min or so. --User:Ceyockey (talk to me) 15:26, 30 August 2013 (UTC)
I don't think anyone has reported this before today, I can still count 27 VisualEdits among the last 500 on this wiki. I also managed to test in my sandbox, and it threw in some nowikis as well, so I'd say everything's nominal :) --Elitre (WMF) (talk) 15:35, 30 August 2013 (UTC)
I restarted my computer and browser and still had this problem. Thus, it is either some problem with my editing environment locally or some problem with the article I've been trying to edit, that being Renault. I'll try some different things later. --User:Ceyockey (talk to me) 17:30, 30 August 2013 (UTC)
Hi Ceyockey, I can get to "Review changes" in that article (I made a minor text change to the lead) but didn't try to save it. It was rather slow; I think it was ten seconds to open the page in VisualEditor, but a bit more than a full minute to get "Review changes" displayed. Were you doing something more complicated? Whatamidoing (WMF) (talk) 21:09, 30 August 2013 (UTC)
One useful first step is to try making the edit while logged out, if that works and your account doesn't then it's likely some gadgets or custom js/css that is at fault. If it doesn't work with either, then its unlikely to be any of those things. Thryduulf (talk) 21:31, 30 August 2013 (UTC)
Thank you!
I was working on an article for a few hours last night and I realized that I've now become faster in VE than I was using wiki syntax -- yay! Here's a quick summary of some of my VE writing observations so far FWIW:
+Cite book is much faster now that I don't need to manually select the parameters every time I use it (thanks Erik).
-But, I still very much look forward to the VE team reproducing the functionality I used to have with wiki syntax, in which I could paste in a book's ISBN and have the rest of the fields autopopulate. That was *amazing* -- it saved me about 90 seconds of tedium per citation.
=I would also recommend that as you revamp the cite tools, please let the user see all the fields and their contents at the same time. Currently I find myself skipping back and forth among fields multiple times, checking to be sure I filled everything in -- which is wasted time. Also, I suspect that the way it's set up currently (separate fields, populated separately) makes it feel to the user like it's more work than it actually is. I think that's because we're used to tasks being broken down into bite-sized chunks, and these chunks are very very tiny bites. (I am writing quickly here -- if that doesn't make sense and someone wants me to try to articulate it better just let me know.)
+The ability to reuse an existing citation is saving me tons of time in article writing: yay and thank you :-)
+But the one major advantage VE has over wiki syntax IME so far, which I expected but have still found remarkably pleasurable/useful, is this: back when I was writing articles in wiki syntax, the actual *act of writing* was impeded by the syntax. What I mean by that is that the mark-up obscured the actual text you were working on, which made it hard to scan for typos, to control pacing and flow, to essentially do any vetting or refining tasks, at all. And, the need to continually distinguish between mark-up and non-mark-up imposed a tiny cognitive processing burden, which was a distraction from the actual work of writing. So, I used to compose and refine in a text editor, and just paste into the editor to add mark-up as a final step. That was slow and kind of painful, and although it worked okay with new articles, it was pretty messy and problematic for existing articles. Now with VE, I can finally compose and refine in the editor and actually *see* the text, not obscured by wiki syntax. This is easier and faster, but I think the real gain is that it enables me, and presumably other writers, to actually *write* better. Yay! and thank you :-)
Hi Sue, thanks for your feedback. I actually think that some of your notes might be usefully added to existing bugs/features requests or VE-related pages, since there are a few remarks that look pretty new to me. I promise you, in a while you'll need VE for almost everything, I am finding out that I often don't seem to be able to add (wiki)links the old way anymore... --Elitre (WMF) (talk) 15:54, 30 August 2013 (UTC)
I completely agree with your third point – and with all templates, not just citation ones. It's like filling out a tax return, but every line is on its own page. -- Ypnypn (talk) 16:37, 30 August 2013 (UTC)
Being a pedantic sort I checked your edit [39] and following bot edit [40] which fixed some minor problems introduced. The main one being the use of |origyear= rather than |year= in {{cite book}}. This was due to an error in the template data, with |origyear= being marked as "required", really it should be either |year= or |data= marked as required but to be even more pedantic neither are actually required just recommended (see T52747).--Salix (talk): 17:05, 30 August 2013 (UTC)
I had the Problem that while I was writing my Change Summary after editing the page I wasn't able to delete what I had previously written i.e. couldn't use delete or backspace. Tathbelin (talk) 20:27, 30 August 2013 (UTC)
This is T52722 which I've just had to reopen. I hadn't experienced it for a while, James closed it early this morning (UTC) but then I encountered it again a short while before your report here. Thryduulf (talk) 21:26, 30 August 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
The mechanism arrows are completely wrong. Whoever drew that does not understand anything about how to draw a mechanism. Please fix it asap. 169.232.142.208 (talk) 22:54, 30 August 2013 (UTC)
This page is for feedback about the VisualEditor. To leave comments about a specific article, please use that article's talk page, although I recommend you phrase things a little softer as your language above reads to me as rather insulting to whomever drew the diagram that you think is wrong. Thryduulf (talk) 23:43, 30 August 2013 (UTC)
This one isn't that major, but I've noticed that when editing in VE, the color of wikilinks and external links are the same. While the shades of blue are noticeably different when viewing an article, this pretty much disappears when editing an article. Like I said, it's not a big deal, but it is handy to be able to detect the difference between the links when editing an article.--¿3family6contribs23:37, 30 August 2013 (UTC)
Yes, this is a known issue. T39901 is tracking it along with redlinks not being red, etc. It doesn't have a target set, so I can't give you an estimate of when it will be fixed, sorry. Thryduulf (talk) 23:45, 30 August 2013 (UTC)
Hi there, I'm copy/pasting from the FAQ here: We think that those who come with the intent to vandalize are probably doing it now because hitting the “Edit source” tab and blanking a page using the wikitext editor is just as fast (if not faster) than doing the same thing with VisualEditor.. Since it takes a while to load and does not allow very fast typing, and this is especially true for large articles, this is not an issue, I think. --Elitre (WMF) (talk) 14:04, 30 August 2013 (UTC)
I know that the VE team were monitoring the vandalism level from when VE was made opt-out in late June/early July, to see whether these predictions were correct. I haven't seen any official results yet, but anecdotally I'm not seeing any noticeable increase in vandalism among articles on my watchlist. Longer term, I don't suspect that there will be any significant difference in the amount of vandalism, but the vandalism will be split between the two editors. Given that is easier to do some things in VE than in the source editor and vice versa, it wouldn't surprise me if the nature of the vandalism differs between the editors. This is speculation though. One thing that is certain is that it makes no difference to the revert tool or anti-vandalism bots, etc, which editor was used so vandalism reversion is exactly as easy as it was beforehand. Thryduulf (talk) 21:15, 30 August 2013 (UTC)
I think 1) en wikipedians largely put trial and error efforts and deliberate vandalism in same basket.It is like counting apples and oranges together.2) en wikipedians use more of stick than communicate to understand and recommunicate to explain.Obeviously the people who fail to understand others views prefer to use stick rather than recommunicating to explain.Over use of stick than explaining the point is the real reason higher percentage of deliberate counter attacks in form of vandalism on en-wiki.And this form of deliberate vandalism will persist irrespective of the system of edit you use until proper communication takes place.(Please note I do not intend to support vandlisers in any way for any reason).
With VE real difference will come in patterns of trial and error efforts.In part wikis need to make edit filters more smarter and effective in part it will need long term studies to understand change in pattern of trial and error and address those issues.
Procedure: Go to this old revision of an article. Scroll down to the equipment section, and note that it includes an image which was deleted. Activate VE. Note that both the entire image box, including caption, are now invisible. When it comes to handling missing images, there are probably a dozen viable alternatives to this approach, all of which would be superior. --Cryptic C62 · Talk02:31, 31 August 2013 (UTC)
Is there a way to list things in numerical order but non-consecutively. For instance, the credits of a music producer who only produced certain tracks on an album. Example: Tyshane. Also, it would be nice to be able to tell the editor to write "01" as opposed to "1". In the case of Tyshane, the track which I wanted to add was the first on the recording, but I still couldn't use VE's numbered list because that only lists "1", not "01". I ended up using User:John Vandenberg's switch editor to pull off this edit successfully.--¿3family6contribs02:59, 31 August 2013 (UTC)
I don't understand your first sentence, sorry. But your second issue isn't possible with the source editor editor either, as VE produces the same wikitext for this - a line beginning with #. It would be certainly be useful to have this, but it isn't (initially) a VE issue I don't think. There is T3584 and T6281 which are sort of relevant. I've reported T55620 for this specific issue, but the numbers of the earlier bugs should give you a clue not to hold your breath for this functionality (they were both reported in 2005), sorry. Thryduulf (talk) 10:01, 31 August 2013 (UTC)
Forget the first part. I didn't realize you can indent the text and type whatever, which is how this type of numbering is done in the source editor.--¿3family6contribs12:45, 31 August 2013 (UTC)
Misspelled title
The following discussion is marked as answered. If you have a new comment, place it just below the box.
There should not be a mark under the second S in the second word. Also, the second word should not be capitalized. Leepdx (talk) 05:21, 1 September 2013 (UTC)
@Leepdx: This page is for feedback about the VisualEditor. To leave comments about a specific article, please use that article's talk page. It is unclear which article you are referring to.--Salix (talk): 06:37, 1 September 2013 (UTC)
The page should be titled "Beaks: The Movie"
The following discussion is marked as answered. If you have a new comment, place it just below the box.
@Leepdx: This page is for feedback about the VisualEditor. To leave comments about a specific article, please use that article's talk page in future. I've now moved the page.--Salix (talk): 06:34, 1 September 2013 (UTC)
nowiki tags
From up above in "Why are we still using this?", the following are responses given to NicoV's questions.
The nowiki tags at the start of the line (<nowiki> </nowiki>Il prit la voie directe allant de Langres à Lausanne...) are a known bug that was fixed in the most recent release (reached frwiki late on Tuesday).
The Alésia mess (...une citadelle religieuse celtique, [[Alésia|<nowiki/>]][[Alésia|<nowiki/>]][[Siège d'Alesia |<nowiki/>]][[Siège d'Alésia|Alésia]]. is T39835.
--Whatamidoing (WMF)
Concerning the supposedly fixed bug. It is still happening. (<nowiki> </nowiki>Local humane societies,...) diff
I was going to give examples of what turns out to be T39835. As the bug is a year old, looks like this won't be fixed and therefore no use in giving the examples.
Why are these happening? (in the [[American Le Mans Series|American Le Mans Serie]]<nowiki/>s and Park Place Motorsport..) diff (is an [[American football]] [[wide receiver|wide receive]]<nowiki/>r who is currently a free agent.) diff (*[[Goat|Goa]]<nowiki/>ts) diff
That should be 51462. I'll reopen it since I can find it on it.wp as well, but it is, IMHO, one of those cases in which the nowikis actually make much sense, since they are invisible andthey prevent text to become preformatted.
Thanks for your opinion. I don't think we should actually stop commenting just because something is either too hard to fix or something else has the priority. Providing more comments and examples - instead than just reporting something won't work - is the only way we have to underline how much an apparently trivial thing means to our editing experience.
I am afraid that might depend on what users select to be linked, or sometimes on them still using the old markup way to create links - ignoring the warning popup. Also see [41]. There are many requests related to wikilinking, if you believe that some intended behaviours should be, well, different, please read the developers comments to the bugs and feel free to weigh in. --Elitre (WMF) (talk) 09:10, 29 August 2013 (UTC)
How about we just use an edit filter to block edits with <nowiki/>, these are always an error unlike legitimate uses of matched pairs. --Salix (talk): 11:54, 29 August 2013 (UTC)
Unfortunately, there are legitimate situations where you can use <nowiki/>: apostrophe before/after bold or italic formatting for example. Of course, other ways exist like {{'}}. --NicoV(Talk on frwiki)12:35, 29 August 2013 (UTC)
I think we should disable using <nowiki/> with the edit filter, as it is mostly caused by VE. We have for cases where we need to break the parser to prevent it misunderstanding apostrophes. There is also <!-- -->. However, if we did prevent this with the edit filter, the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible.(is there a bug tracking the invisibility of the nowiki tag? We can add more edit filters once bugzilla:47779 has been fixed. John Vandenberg(chat)14:44, 1 September 2013 (UTC)
is there a bug tracking the invisibility of the nowiki tag? I wasn't able to find one, so I've added T55659, but I'm not sure I've explained it brilliantly. Thryduulf (talk) 15:36, 1 September 2013 (UTC)
Copy and paste in style editor produces weird behavior
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Pasting a sentence that includes bold text and a link (may not be requirementa) is un-editable. Trying to edit a part of the sentence deletes the entire thing, as if the entire sentence was selected instead of one word. Trying to insert a word also overwrites the whole sentence. WildElf (talk) 03:18, 30 August 2013 (UTC)
I didn't save the edit. However after reproducing it several times to gather more info, I disabled my add-ons. Sure enough, 'disable clipboard manipulations' add-on was the problem. There is no issue with wiki code. Sorry for the false alarm. --WildElf (talk) 04:25, 30 August 2013 (UTC)
Thanks for the update. I'm glad that you figured it out. If you see anything else strange, please don't hesitate to let us know. I'd rather have a false alarm than an unreported problem. Whatamidoing (WMF) (talk) 20:55, 30 August 2013 (UTC)
User:Markhurd editing while logged out. I can't see where people might think this is article feedback.
But I have seen two issues to note:
1. This "Submit Feedback" form's blurb should end with "your username or IP address, if not logged in."
2. It's grabbing bolded text immediately after an image (i.e. no whitespace in between ]] and ''') and duplicating it; not allowing you to edit it and the Show Changes shows it will duplicate it. 121.45.55.242 (talk) 15:23, 30 August 2013 (UTC)(That was me logged out Mark Hurd (talk))
Searching for "duplicate" doesn't obviously find existing reports of this.
See this edit [42]. I confirmed it is not specific to being not logged in by attempting a VE before fixing the problem using edit source (and avoiding it by inserting a new line).
Interestingly this page was immediately previously edited by an anonymous VE 7 hours before and it didn't have a problem. So either you've recently pushed out a new build or it is browser specific (mine's Chrome) or something.
I'll report it on bugzilla if I can't find a duplicate there.
I haven't reported it because it's no longer repeatable! I tried here, and here and even went back to the original page and made it look the same as it was before I attempted to edit it earlier and it worked fine :-(.
It is reproducible just edit the old revision [43] and bingo duplicated text. Its a very odd error, I copied and modified the text in my sandbox and it manages to duplicate text which is not actually in the revision being edited[44]. --Salix (talk): 18:02, 30 August 2013 (UTC)
So {{template}}'''Bold''' text results in the bold-face text being removed. This also happens with [[link]]ed or ''italicized'' text immediately after a template. Have you tested those options as well? Whatamidoing (WMF) (talk) 21:01, 30 August 2013 (UTC)
I tried those when I attempted to reproduce it, but they all worked fine. This issue is really finely based upon the rest of the article's content. If you try each of the revisions since Old revision of Danny Nalliah, you'll see that one is fine, the next one where the only change is a pair of extra double quotes have been added in a paragraph in the next section has the problem, and it continues until I explicitly put in the sensible line break, and yet it doesn't return when I take it out again (with my SBS correction still in place)! (well that was what happened Friday...)
And now things have changed since Friday: Now the problem is occurring in the latest version (and thus two versions before as well) but still NOT in the version where I just removed the new line... This is all originally checked when I'm not logged in, but I get the same results when I am.
So someone added a book to a ==Further reading== section. Book #1 used a citation template. Book #2 did not. Neither had bullet list formatting.
Selecting them was hard. I ended up selecting the header, the template, and the plain-text citation. Then I clicked the 'list' button. Then I went back and repaired the formatting for the section heading. This isn't necessary, but it was easier than trying to figure out the exact stop to place the cursor. Here is the (correct) result.
But the display was odd. While I was in VE, the bullet for the first citation was at the start of the second line of the citation, not the first. It still displays this way now, if you just edit the page in VE. Has anyone else seen this? WhatamIdoing (talk) 04:36, 31 August 2013 (UTC)
Yes, the display issue is T53760. That's been sat unprioritised for over a month though so who knows when it will be fixed.
The first problem is that it's hard to select just the line that contains the template. You have to find the magic spot in the middle of "==Heading=={{template}}" to select the template without picking up the entire section heading. I managed it later in testing, but only if I'm selecting text with arrow keys. With the trackpad, it's still beyond me. WhatamIdoing (talk) 04:37, 1 September 2013 (UTC)
Ah I understand now. I've genericised and added your comments to T54302, which was about very similar behaviour in a slightly different circumstance. Again that has been prioritised since July though. Thryduulf (talk) 12:16, 1 September 2013 (UTC)
I've a feeling its some javascript or css altering the links after the page is rendered. There has been some javascript trickery which changes the labels on things. Examining the source:
the first link should show as "view" but because it matches the css rule span.mw-editsection a it is changed somewhere along the line to be "edit source". This has been done so normal section edit links display "edit source" to distinguish them from the VisualEditor its just that rule has also caught these links which should not be changed. I'm not quite sure yes where the css/js is modified though.--Salix (talk): 07:38, 1 September 2013 (UTC)
VE inserts the section name into the edit summary if the edit session begins via a section link, but that doesn't constrain the person doing the edit to just editing that section. VE displays, and allows editing of, the entire page. [An interesting thought: should it? It could display the entire page but restrict editing to the section that was opened.]
VE also doesn't track which sections have been edited - that is, it won't change the edit summary information that it posted (regarding the section) if an editor goes outside that section. In theory, this is a bug - but it seems to me that it's quite difficult for VE to track what sections are edited (or even that multiple sections have been edited). And then there would be issues like the edit summary info being changed by the user, then the user does some more editing ...
Finally, I note that with the wikitext editor, a person can change the section information in the edit summary, including deletion. And a person can add what appears to be section information - so, for example, to edit a whole page but mark the edit summary as if the editing session involved only a single section.
Bottom line: if the user has a pattern of there being misleading section information in the edit summary, it's worth pointing this out to him/her. Or if there is some other reason to suspect malice (as opposed to having opened VE to edit, and wandered off to a different section, or even just to have clicked on the most convenient section link), then one should assume good faith and politely suggest that in the future, he/she should be more aware of what the edit summary should be. -- John Broughton(♫♫)20:13, 1 September 2013 (UTC)
There are three relevant bugs here. The current behaviour was requested at T52872, the request to base the edit summary on what section was actually edited is T53903 and the request to handle single-section editing (as in the source editor) is T50429 although I can't at a quick glance spot that making only section editable has been suggested. Thryduulf (talk) 23:26, 1 September 2013 (UTC)
Sorry still working on to report the issues in the thread , so bringing it back from achive
VE + ULS unicode Devnagari Script input issues
Hi,
With reference to bug no 49569. From my todays test edits at mr wiki, it seems some efforts have taken place to initiate/enable ULS unicode Devnagari Script input in VE edits.But for practical usage,even for primary begining, it seems to have too many issues yet.Before informing the issues do we wait untill we are officially informed from your side or do we start reporting issues ?
I suppose till now there is no separate bug to track "VE+ULS unicode Marathi language Devnagari script issues". Would you prefer to start a separate bug for tracking or you expect us to join with some existing bug reports for related issues.
Hey Mahitgar, Elitre. As VE will not be usable on wikis where ULS isn't integrating properly, I'd be filing this as a VE bug, and as a "blocker" to Marathi deployment depending on severity. It is fine to file as a separate bug - if the devs discover it is linked to another reported issue already assigned, they can merge the reports. Mahitgar, can you give us a more detailed report about the specific issues you are noticing on mr.wiki, as well as the browser and operating system of your computer? With that, we can submit a actionable bug report, and work to get this fixed before any rollout to Marathi. Can't offer much insight to this particular script - I haven't been working with the Indic languages - Jan and his team are working on this. User:JEissfeldt (WMF) - tag, you're it! PEarley (WMF) (talk) 16:33, 23 August 2013 (UTC)
Thanks, I have the CIS in Bangalore putting together a file on critical bugs for Indian language versions for this product since yesterday and will expand it as necessary. This looks like a solid candidate to me, regards --Jan (WMF) (talk) 18:00, 27 August 2013 (UTC)
Thanks for all above replies.I will study and list problems for Marathi language VE+ULS environment here in a tabular form over couple of days
VEplusULSinput Akshrantaran issues 2 with normal speed typing cursor moves to left it is supposed to move to right direction
In normal speed typing,after we type first alphaabate cursor moves from right to left direction.Word marathi need to apear मराठी with VE+ULS instead is coming राठीम
Marathi language devanagari is written in left to right direction.But when we use ULS Method of input = अक्षरांतरण with VE cursor is moving in opposite direction as if we are typing a right to left script
VE+ULS Method of input = अक्षरांतरण (Non-VE source edit environ,ULS Method of input = अक्षरांतरण works normal
mr:अभिमन्यु and all other articles with text already present
Screen shot or diff Not possible without video recording itself of VE's moving self action
spell correction of any word eats up text on right side until you press space bar
उदाहरण
VE+ULS Method of input = अक्षरांतरण (Non-VE source edit environ,ULS Method of input = अक्षरांतरण works normal
Firefox+Win7
53757
5
Any random selected article on mr-wikipedia
Wont be defficult to provide screen shots , Still need more usage pattern observation before providing screenshots to provide steps to reproduce
Where text is already present,Along with any of above problems, Some times edited aspect is shown in edit window but does not reflect in edit preview
Probably problem arises when we insert any additional charecters or word between two existing words in a sentence.I suppose this would be easy to reproduce.
VE+ULS Method of input = अक्षरांतरण (Non-VE source edit environ,ULS Method of input = अक्षरांतरण works normal
Firefox+Win7
53758
6
Any random selected article on mr-wikipedia
Image to be provided
If for spelling correction purposes only few charecters within any word are selected and replaced with other charecter of same or lesser length, without movement of arrow keys or spacebar, save button does not get enabled, so effectively we would not be able to save the change
Behaviour seems to be indirectly related to above point 5 testing for the same going on
Bug 53788
7
all articles
Do we need image for this
need enabling ULS input in Link,Reference,Category and template edit-windows
Following most required marathi language typing pattern produces marathi sentense as given below in ULS input अक्षरांतरण (transliteration) using roman engilsh "qwerty" key board in traditional wikisource editing; The target for VisualEditor team is the same to happen smoothly for VisualEditor+ ULS input अक्षरांतरण (transliteration) environment.
most required marathi language typing pattern example
Thank you, Mahitgar. This is really helpful and will be a core part of the set of issues I will take to the office during a visit mid September. I feel the relation between VE and ULS will stay with us longer than the format of this feedback page permits. Therefore, I suggest to move the topic to my talk page; where I'm automatically notified in case you expand your findings there and we don't have to rely on Elitre for pings - although she does an excellent job in keeping the issue high up my radar :). Beyond Mr.WP itself, I'm also perfectly prepared to take on board issues you find on Hi.WP or generally VE bugs across Indian language projects you see as critical and feel they should be highlighted by me. Best regards, --Jan (WMF) (talk) 15:45, 31 August 2013 (UTC)
Thanks for very positive response.Your suggession is most welcome I will place this discussion on your talk page and add further aspects there.Besides mr I can certainly bring in info on hi sa and ne wiki over coming week.
@Siddhartha Ghai Thanks for nice support in reporting the bugs. I wish and request to have a look at bug 53754(not in above list) and please do check for hindi language too.
The following discussion is marked as answered. If you have a new comment, place it just below the box.
I have tried the visual editor a few times but found it slow, clumsy and error producing. What I would like is the option of a visual editor which shows the Wiki code, as a transition to a full visual editor.
What I found myself doing is seeing what Wiki code the visual editor produced, canceling the changes the visual editor was making and then manually pasting that code in with the old editor.
As an example, I was editing the entry on Marc_Newson, to add a new bullet point. I copied and pasted the existing entry about the Qantas 'Skybed' and edited it to make a new entry about the 2013 Qantas A330 Business Suites. The entry had a reference, which was copied along with the text. I edited this thinking it would create a new reference. But lucky I checked, as what this was doing was editing the existing reference, not creating a new one.
T49779 requests there be an easy way to switch between the visual and source editors. I can't find it at the moment, but I'm pretty sure the request for a live preview/side by side editing of visual and source was closed as WONTFIX, sorry. Thryduulf (talk) 12:06, 1 September 2013 (UTC)
I suspect the side by side VE/wikitext display would be a huge challenge. The VE is an HTML editor. When started it converts wikitext to HTML, you edit the HTML, and when you save it converts the HTML back to wikitext. A quick-flip from VE/wikitext or side-by-side VE/wikitext would be as slow as the current loading of VE and saving a page from VE.
I would consider the part about where Tom Worthington copy/pasted some text and when editing a reference it modified the original reference and not the copy to be a bug. It should be creating a new ref to the same location. When you save the VE would check for identical refs and merge them together using <ref name="..."> --Marc Kupper|talk19:42, 2 September 2013 (UTC)
I suspect that you're right, but that simply underlines the massive architectural flaws at the heart of the visual editor, which no amount of string and sealing wax will ever be able to hide. EricCorbett19:49, 2 September 2013 (UTC)
Autocomplete
The following discussion is marked as answered. If you have a new comment, place it just below the box.
It will be a good idea to include autocomplete in Add Parameter when editing Infobox. For example if we want to include Development Status in our software infobox the autocomplete should suggest to include "status" as the user types Development or Status. RyanJon2040 (talk) 05:35, 2 September 2013 (UTC)
I think this will be fixed by T53670, which is fixed and awaiting deployment (due here on 12 September). If it isn't then possibly T53822 will handle it to (that's a normal priority enhancement with no target yet set). I'll ask for clarification though. Thryduulf (talk) 10:53, 2 September 2013 (UTC)
It might just be that {{Infobox software}} has not yet had it TemplateData added yet. Without that the software does not know what the parameters are, so its imposible to try and autocomplete them. You get better results when the template data has been done like {{Infobox company}}. I'll see if I can get the TemplateData for that sorted soon.
On a related note I'm increasingly just using the parameter name as the label. Having two different names for the same item just makes things confusing.--Salix (talk): 11:33, 2 September 2013 (UTC)
I think Salix is right. RyanJon2040, if you try to add template:Infobox website to a sandbox instead, you'll find out it suggests the right parameter (for example, if you start typing Programming Language, after a few characters the related parameter will be easier to select, although it won't "autocomplete"). For templates already featuring TemplateData and which have required parameters, you'll find these already listed in the left side of the template editor instead. --Elitre (WMF) (talk) 11:53, 2 September 2013 (UTC)
The following discussion is marked as answered. If you have a new comment, place it just below the box.
You list Giuseppe Garibaldi's place of birth as Nice, First French Republic. In truth, Nice was part of the Kingdom of Sardinia in the year of Garibaldi's birth and was ceded to France many years later by the Kingdom of Sardinia. 64.175.36.88 (talk) 00:55, 3 September 2013 (UTC)
Well, thanks :) On an unrelated note, I'll let you know that in my volunteer capacity I participated to Wikipedia:School_of_Open_course/Round_3/Week_5 today, where I could briefly speak about VisualEditor, and was actually pleased to get some positive feedback from the students and organizers. I really hope they can enjoy it fully in the near future. --Elitre (talk) 21:58, 3 September 2013 (UTC)
Khulm River
The following discussion is marked as answered. If you have a new comment, place it just below the box.
User-added accented characters in table cells cause cell text not to display properly. Attempts to save this new input lose the accented Unicode characters.
To duplicate:
See fr:Route 2 (Ontario) and its revision history, the distance chart is a table and Unicode descriptive text added with VisualEditor didn't save properly.[45] The damage was fixed using the standard MW wiki source editor but is still in history. Try inserting « La route 2 va à Montréal (Québec) » (or something/anything that isn't US ASCII) into a table cell and watch it fail to display correctly or fail to save.
Operating system
Ubuntu
Web browser
Firefox
Site
Fr-WP
Workaround
Edit the page with the old source editor to put the accents in their proper places.
It looks to be any attempt to type new accented « charactères » into table cells, even if they don't represent clickable links, poses problems. Thanks. K7L (talk) 14:38, 3 September 2013 (UTC)
Yes, there is some significant problem here (see the linked section above for the results of my testing, it isn't just confined to table cells). The bug has been prioritised as "highest" so it hopefully shouldn't be too long before its fixed. Thryduulf (talk) 15:17, 3 September 2013 (UTC)
Indeed I am seeing the same problems if I try to edit ordinary text such as the article intro. Pressing <save> or even <backspace> makes accented characters in newly-edited text vanish. This editor is not usable for non-English text on this browser. K7L (talk) 15:03, 4 September 2013 (UTC)
If you then try and re-add the disappeared characters it appears to work, but when you do something else they become pawns. The problems have been reported though and the devs are aware so there isn't any more we can do currently :( Thryduulf (talk) 15:14, 4 September 2013 (UTC)
Really slow
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Edit source isn't blazing fast, but VisualEditor is slow enough to feature in a Comcast commercial. Really, we need to get enough render bandwidth in place before deploying such heavy weight pages. Wcoole (talk) 23:58, 3 September 2013 (UTC)
Not my best section header here :-) What I mean is this: someone tried to change [[Compton, California|Compton.]] to [[Compton, California|Compton]], [[California]]., but end up with [[Compton, California|Compton]], [[California]][[Compton, California|.]] In the visual editor, this is nearly impossible to see. It's perhaps not a real bug, but it's the kind of thing that happened a lot less in the old editor than in VE. Fram (talk) 09:37, 4 September 2013 (UTC)
Yeah. That used to be common (T52945) but that has now been fixed. I can reproduce that by added a space before the full stop and adding the new link there, but that is desired behaviour as far as I see it (if a user splits a link both parts should remain linked unless explicitly unlinked). The problem is that the full stop shouldn't have been linked in the first place, but given that it was the user didn't spot it was linked and didn't unlink it. I don't see what VE can be expected to do differently here? Thryduulf (talk) 11:41, 4 September 2013 (UTC)
No idea what VE can do differently, it's just an aspect where the old editor is superior; the chance of someone by accident changing that original link to 3 links in the old editor is quasi nihil, while it is rather predictable here. Fram (talk) 11:45, 4 September 2013 (UTC)
Yeah, it being less obvious that a small character is a link is a side effect of WYSIWYG unfortunately. If you can come up with a way to get around that do say, because I agree it's not optimal but I can't think of how to get around it. Thryduulf (talk) 12:02, 4 September 2013 (UTC)
Removing a section plus header should not result in an empty section header
[46]; when an editor selects a section plus its header and removes it, the section header isn't really gone but gets one of the dreaded "nowiki" tags. When does someone really want an empty section header? Apparently VE is smart enough to recognise the need for a nowiki to separate the left and right sides of the section header, but isn't smart enough to just remove it altogether... Fram (talk) 10:10, 4 September 2013 (UTC)
The VE has a number of differences between the actual page and the look in VE, most rather minor but somewhat annoying, like the abundance of spaces in and around templates (e.g. in quotes, or before and after notes and references).
A more prominent and for me harder to understand difference exists with reused references. Normally, they are shown as e.g. 1. abc, but when in VE mode, they become 1. 1.0 1.1 1.2 (there is also a difference between the upward pointing symbols). I can see no reason for this, and for me, the VE version is actually harder to read than the traditional method, because it is unclear that the 1.0 and so on are not a part of the reference, but indicate that the reference is reused a few times. I would suggest that either the same look as in normal viewing mode is taken, or that they are removed (in VE only) altogether, since they can't be used in VE anyway.
The spaces round templates are slugs that attach a template to a given position on a page and allows them to be better interacted with and T49790 requests that it be made clearer they aren't really blank lines.
The repeated reference numbering issue is that the 1.1 1.2 format is the default way repeated references appear on all wikis, but some (including the English and German Wikipedias) have chosen to use the non-default a b c format. VE presently always shows the default, but T53453 asks for VE to use the local preference format instead. Thryduulf (talk) 11:59, 4 September 2013 (UTC)
VisualEditor suggesting authority control?
The following discussion is marked as answered. If you have a new comment, place it just below the box.
On Johann Daniel Bager, in the Authority Control template, the only parameter at the moment is the VIAF one. However, on starting VisualEditor, a GND number is added as well. When editing the template through VE, the GND parameter is not yet present. I suppose these are found through Wikidata or some such, but what is the actual purpose? It is rather confusing, and not really helpful (considering that when I want to add a parameter, the suggestions (if that is what they are) are actually hidden beneath the template edit window). Similar issues can e.g. be seen at Johann Friedrich Bause or Johann Peter Krafft. Fram (talk) 11:29, 4 September 2013 (UTC)
I don't think this is a Visual Editor bug. You get the same behaviour when you edit the page using the wikitext editor.[47]{{Authority_control}} is getting its data from wikidata [48] which has both VIAF and GND data specified. When you edit the page with either editor, the page is re-rendered with the output of the template recalculated with the latest wikidata. Hence both are displayed. Simply viewing the page just uses an old cached version without the updated version. Doing a null edit or such like will bring the page upto date.--User:Salix alba (talk): 11:45, 4 September 2013 (UTC)
I see. You still get the effect that the template shows two parameters, but the source only has one, which is rather confusing, but not really a VE bug. Fram (talk) 12:11, 4 September 2013 (UTC)
If you try and use beta to edit a page, but you've forgotten to log in, so you log in directly off the beta page, once you have successfully logged in it takes you back to the edit source page instead of the beta page. Minor, but thought you may want to correct it? Professor Hog (talk) 11:50, 4 September 2013 (UTC)
Thank you for that, I've reported it as T55746. I'm not a dev, but to me it doesn't sound like a big problem so hopefully it shouldn't take long to fix. Thryduulf (talk) 12:11, 4 September 2013 (UTC)
@Professor Hog:, although I can reproduce this in Firefox 23/linux it seems that James F can't. To help identify what the problem is, please could you let us know what browser and operating system you use, and also whether you use any editing gadgets. Thanks, Thryduulf (talk) 16:40, 4 September 2013 (UTC)
Sorry still working on to report the issues in the thread , so bringing it back from achive
I'm in the middle of article editing at the moment so this is partly an aide memoir for me when I have time to test it and partly a request to see if it is happening to others.
I'm finding that at least sometimes when trying to wikilink an existing work that contains an accented character, e.g. Marília, Bogotá that the accented characters are getting deleted. When trying to undo that the whole word (sometimes?) gets deleted. All this is in table cells, I haven't tried outside or with characters that are not in basic ASCII but are not accented Latin Characters. Everything seems to work fine when using the link dialog to add a link and the text at the same time.
I'm also sometimes getting strange corruption/duplication of text when adding a word with accented characters in a table cell.
Just now linking the text "Bogota" to Bogotá, deleting the "a" and typing "á" included the letter in the link as I wanted but when I went to link another word the "á" became a pawn :( Firefox 23 / Linux / Monobook for all of this. Thryduulf (talk) 00:02, 2 September 2013 (UTC)
I deleted the pawn, put "á" there. It showed as "á" but a pawn was saved [49] (4th last change, an in-page search for "Avianca" is likely the quickest way to find it). Thryduulf (talk) 00:15, 2 September 2013 (UTC)
I don't think I've got to the bottom of this yet, but experimentation in my sandbox has shown that it is unrelated to tables, and happens everywhere. It seems that the key thing is annotating or linking words containing accented or non-Latin characters. Doing so frequently causes the accented character to disappear. Re-adding such a character (not necessarily the same one) causes that character to (usually) turn into a pawn when anything else on the page is linked. I've reported what I've found so as T55680 but it would be useful to confirm this in other browsers, etc and if possible refine the cause a bit more. Thryduulf (talk) 13:37, 2 September 2013 (UTC)
I've been doing a little testing in my sandbox. This is kind of a fun little bug if you want to make a huge mess. Typing Résumé writing for fün and profít displays like this on screen:
Résumé writing for fün and profít
s
n
(The stray 's' and 'n' appear on their own lines immediately after being typed in the sentence above: it's the 's' from the middle of Résumé and the 'n' from the end of fün. But the saved results are this:
R
ums writing for f
and profnt
Notice that the letters with dicritics disappear, and that the stray 's' is removed from Résumé and re-appears where the second é in Résumé is supposed to be, and the stray 'n' has been removed from fün and replaces the missing í in profít.
I think the newlines are an artifact of having a {{reflist}} template without actually having any references in the body of the article, but I haven't done any testing (such as actually adding a citation) to confirm this. Assuming this is a bug, it's a fairly minor one. -- John Broughton(♫♫)23:01, 2 September 2013 (UTC)
They're caused by the blank lines between the refs, the categories, and the interwiki links. In my sandbox, they appear even if a ref is added to the page. Whatamidoing (WMF) (talk) 15:57, 5 September 2013 (UTC)
At any given page, example, as long the edit box is selected (with the cursor blinking) pressing 'page down' or 'page up' takes you to the end of the page. Firefox 23.0, Linux Mint. 177.148.217.222 (talk) 12:45, 4 September 2013 (UTC)
Hmm, on that article with Firefox 23 on Xubuntu Linux using the monobook skin, I find that pressing page down or page up works as expected once but then does nothing. I then click anywhere in the body and again one of them works once, and then not until I click. However, once I've viewed the end of the page it expected. I see exactly the same at User:Thryduulf/sandbox2. At User:Thryduulf/sandbox it works as expected from the start. At Nigeria I saw the same behaviour as at Jet Lee (your example), but when I returned to the top of the page it went back to working only once. This is very bizarre! Reported as T55750Thryduulf (talk) 13:14, 4 September 2013 (UTC)
Maybe a related error occured, while testing in Nigeria, Firefox 23, mono. Enter VE-mode and click below one of the huge (really huge) navbox farms at the end of the article (in the blank line below them). Now i made two tests:
Click "Page up" => OK, scrolls up as expected. Now click "Page up" again => ERROR, jumps down to the initial position below the navbox.
another test from the same initial position below the huge navbox: "Page up", then "Page down", then "Page up" and a second "Page up" => works OK.
If i had to guess (uneducated as always), it looks like VE has problems storing or establishing the cursor position while scrolling through some huge or complex templates. GermanJoe (talk) 11:35, 5 September 2013 (UTC)
Please could you be more specific - which article? In what way were they messed up? What were you attempting to do? I've had a look through your recent contributions and can't spot where VE has messed up any tables. There is one case [50] where it nowikied a + following an {{nts}} template that I'm about to investigate, but that doesn't seem to have messed up the table or the sorting afaics. Thryduulf (talk) 00:38, 5 September 2013 (UTC)
Hmm, well I can't reproduce that error in my sandbox or when previewing that article using firefox 23 on linux with the monobook skin. @Greenrd: it would really help if you could also give the information I asked for above along with your browser and OS. Thryduulf (talk) 01:00, 5 September 2013 (UTC)
Sorry, I assumed that the feedback form would automatically add which page I was on. It was [51]. Tables are displayed incorrectly, before I edit anything. Scroll down the page and it gets worse. I'm using Chromium 27 on Linux.--greenrd (talk) 07:13, 5 September 2013 (UTC)
Yes that is a good idea :) As for the bug, it was the one I thought and it's just a rendering issue in VE and the output isn't affected. That's not good exactly, but it's not as bad as it could be. Thryduulf (talk) 16:52, 5 September 2013 (UTC)
Whatever is causing that it's a different bug from the one above so I've given it its own section. The cause is the linebreaks in the table cells (see. [52] for example). If VE inserted them then it's a bug that needs fixing, but it's not something I've ever seen it do before. Could you have added them? Thryduulf (talk) 18:13, 5 September 2013 (UTC)
The problem is not with VisualEditor. For some reason, if you press the return key to add another line (rather than adding a <br> HTML code), that table breaks. It doesn't matter whether you add the line break in VisualEditor or in the classic editor. On the other hand, if you reformat the wikitext table to have one cell per line, then it works fine. Whatamidoing (WMF) (talk) 18:17, 5 September 2013 (UTC)
Keish origin correction
It states in the bio that the native Keish is Tahitian. This makes no sense when he was born in the Yukon of the Taglish native group.
Thanks,
Maja 206.41.91.42 (talk) 20:15, 5 September 2013 (UTC)
Classification of water body type is not dependent on hydrological links whether present or not. The "great lakes" of north america are great inland seas. Lakes are characterized by being surrounded by land but also by size. 173.17.134.122 (talk) 02:06, 6 September 2013 (UTC)
There are no references with the group "" on this page
When a page has <references/>, but no actual references, the above text appears in grey at the location of the references template. I think that the part "with the group """ should be removed, as it is confusing and unnecessary (references don't need a group, the group "" is not used on the page, the problem is simply that there are no references with the "ref" style at all). Example: N.O.T.R.. Fram (talk) 09:34, 4 September 2013 (UTC)
I agree that the message isn't brilliant, but it's not as simple as there just being no references. That message can appear when there are references in a group other than "" (e.g. notes) but none in the default group. Because of bugs it can also happen when there are references inside elements (e.g. a blockquote) and the reftag is outside it (see for example at Waltzing Matilda#Lyrics). Thryduulf (talk) 11:34, 4 September 2013 (UTC)
But at the Waltzing Matilda page (where the cite error and this message are clearly a bug), there is at least a named group, so the reference to "group N" is understandable. When there is no named (or unnamed) group anywhere at the article, there is no reason for the message to mention 'group ""'. Can one even use a group "" in reality? I doubt it... Fram (talk) 11:51, 4 September 2013 (UTC)
Group "" is the same as no group, i.e. if you add a reference to a page without specifying a group it is in group "". Saying "there are no references on this page" is true in the majority of cases but not always is my point. Would "there are no ungrouped references" or "there are no references in the default group" be better? Thryduulf (talk) 12:05, 4 September 2013 (UTC)
I don't doubt that your explanation is technically correct, but this is meaningless to editors. Either they know about refs vs grouped refs, or they don't know about grouped refs at all, but in either case, the empty or default group is not something they will ever be familiar with. Of your suggestions, "ungrouped" seems like the best one. Of course, one can argue that no message is needed at all (certainly when it sometimes is given incorrectly), but that's a more philosophical point. Fram (talk) 12:15, 4 September 2013 (UTC)
May I suggest a better translation from tech geek into English? How about replacing 'no references with the group "" on this page' with 'no references on this page from the default grouping'. Other groupings would be displayed as 'from group "X"'. This is a bit more natural language. It requires assigning a special case to the null set, but, really, you should get used to that, after all, even if VE has probably another 6 months before it handles things like tables and templates well enough to really take off with the group, in the long run, this is meant to develop into a tool for newbies, and it's better to think ahead now. Ideally, you should likely drop "from the default group" in the absence of non-default-group items, and, unless there's a good reason not to, I'd go with the ideal. =) Adam Cuerden(talk)08:10, 6 September 2013 (UTC)
Just to be a bit clearer: VE, as it is currently, is not an ideal newbie tool. Template and table editing is a bit rough, it could use a few more interaction methods, since form-based editing isn't ideal for everything, and so on. But you're going to move past those issues in, say, six months to a year. At that point every decision you made where you didn't think to simplify text to make it clear for new users is going to come back to bite you, because, at the moment, VE may be somewhat hard for newbies, but once it's easy, this page is going to light up like a Christmas tree, because all the text that was, at the time, "good enough" is no longer going to be. Better to think ahead now. Adam Cuerden(talk)08:22, 6 September 2013 (UTC)
What browser and operating system are you using? Are you using any gadgets? I wasn't able to make any changes using Firefox 23 on Linux. Thryduulf (talk) 17:02, 4 September 2013 (UTC)
I also tested it on that Katy Perry's page, I basically added a few letters and the preview was pretty messy. Thanks NicoV for reporting it before I did. --151.42.253.105 (talk) 17:59, 4 September 2013 (UTC) (Elitre WMF)
It's apparent that Visual Editor is no longer respecting the protected node. Opening a bugzilla report.—Kww(talk) 18:01, 4 September 2013 (UTC)
T55767. Commentary to assure developers that the ability to protect an article that VE cannot handle from being corrupted by VE is a critical need is appreciated.—Kww(talk) 18:09, 4 September 2013 (UTC)
I can't reproduce this on NicoV's test page nor in my sandbox, so it seems like it might be browser-dependent - it would be helpful if you could note what you were able to reproduce it in. Thanks for the report though. Thryduulf (talk) 18:22, 4 September 2013 (UTC)
I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... --NicoV(Talk on frwiki)11:05, 5 September 2013 (UTC)
The quotes all seem to be changing <ref name=foo> to <ref name="foo"> which is not really a problem as afaik they are meant to have quotes. The table corruption will be no different to what would have happened without the protection. The cause of the issue was fixed on the main article so the hack (and it is just that) to stop VE is no longer needed there. The underlying problem is the way Parsoid deals with malformed tables, which is known but proving tricky to fix (at least partly as there are countless ways to malform a table). Thryduulf (talk) 12:02, 5 September 2013 (UTC)
The main reason for my last report was to say that even with Firefox, it's possible to edit a protected node, just a little more difficult than with Chrome, so the problem is not limited to one browser. After that, I must confess that I didn't really check it the second edit had more things screwed that the first one, but I didn't remember the changes on the quotes, the pipes and the spaces in the first edit. --NicoV(Talk on frwiki)21:35, 5 September 2013 (UTC)
We just shifted versions an hour or two ago. Would you mind clearing your cache and trying to reproduce this again at any Wikipedia (that's version "wmf15") and again at mw:Sandbox (which is version "wmf16"; the Wikipedias should get it next week)? That will tell us whether the problem persists despite the most recent upgrade. Whatamidoing (WMF) (talk) 21:44, 5 September 2013 (UTC)
I cleared the cache of my Chrome 29 (both in the settings and by doing a Ctrl+F5): no change at all, no problem for editing my test page. I won't be able to test on the other computer (FF17+XP) before 10 days. --NicoV(Talk on frwiki)21:51, 5 September 2013 (UTC)
It might be a good idea to make the hack official for now, perhaps something akin to page protection - a length of time (up to one year) can be set to protect an article from VE, depending on the bug, and an estimation of when it's likely to be fixed by. VE is improving constantly; it would be better if there was a way to turn the protection off after a time, to make sure it's still valid. Adam Cuerden(talk)21:54, 5 September 2013 (UTC)
Where it is known which bug is responsible for messing up a given page then it would be useful to somehow note that so that when the fix for that bug is deployed we can check the page and then remove the VE protection if it no longer breaks rather than some arbitrary time period. I can't remember how of the top of my head, but I know it is possible to generate a list of bugs fixed in a release (although would that cover just VE or VE and Parsoid?) that we could check against. Where the bug isn't known it would be worth checking every release. I'm not sure how to do this tracking though? Thryduulf (talk) 22:09, 5 September 2013 (UTC)
Easily enough done when VE learns to respect something. Tag the template with a bug number, and have a bot go through every night and remove all templates related to closed bugs. It looks like the big problem is convincing developers that this is a real issue: that we need a way to keep VE off of an article while we are trying to figure out what the problem is, and correcting the wikitext that drives VE bonkers rather than fixing VE so that it doesn't go bonkers is cheating.—Kww(talk) 22:35, 5 September 2013 (UTC)
A template system basically means doing it based on page content. Another method might be some sort of metadata that VisualEditor responds to.
Realistically, how many articles are involved? If it's dozens or hundreds, then I think that we could manually log the pages and review them every now and again. If it's thousands or tens of thousands, then we'd need some sort of automated or semi-automated process, even if it was as limited as "protection falls off every three months". If it was a bot, then I'm not sure I'd bother running it every night. We're looking at code releases usually once or twice a week, so a weekly run would probably be adequate. Whatamidoing (WMF) (talk) 01:03, 6 September 2013 (UTC)
Did you subst those as well? Special:WhatLinksHere/Template:Disable_VE_bottom gives very similar results. If there isn't another template, then, unless you subst'd hundreds of articles, I think it's safe to say that it can't be that many articles, though said articles are now invisible. To prevent this in future, I'm going to add a Category to Disable VE top. Adam Cuerden(talk)06:56, 6 September 2013 (UTC)
New:
Cryptic C62 · Talk 23:06, 11 August 2013 (UTC)
Facepalm . Quite right; they do for me, too. I should have RTFM. Still, the de-headering is disconcerting, and I would have expected "Return" to reverse it. JohnCD (talk) 17:46, 12 August 2013 (UTC)
text. However, this still doesn't allow you to paste it into other articles, which, as you point out, would be a very useful feature. --Cryptic C62 · Talk 22:41, 16 August 2013 (UTC)
.
Acknowledged
references icon will add the <references /> block.
