I was under the impressione that, when overwriting, some words were skipped, i.e. they were deleted. [[User:Ithunn|Ithunn]] ([[User talk:Ithunn|talk]]) 19:02, 13 August 2013 (UTC)
I was under the impressione that, when overwriting, some words were skipped, i.e. they were deleted. [[User:Ithunn|Ithunn]] ([[User talk:Ithunn|talk]]) 19:02, 13 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? [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 20:19, 13 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? [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 20:19, 13 August 2013 (UTC)
== Increase loading and performance speed please. ==
This is very important. Loading the source is still faster. Thanks.
Attention Internet Explorer (IE) users: VisualEditor is temporarily disabled for IE9 and IE10 users, due to various issues that are being fixed. VisualEditor will not be made available for users of IE8 and earlier; such editors should switch to some other browser in order to use VisualEditor.
Share your feedbackReport bugsYour feedback about the VisualEditor beta release
This page is a place for you to tell the Wikimedia developers what issues you encounter when using the VisualEditor here on Wikipedia. It is still a test version and has a number of known issues and missing features. We do welcome your feedback and ideas, especially on some of the user interface decisions we're making and the priorities for adding new functions. All comments are read, but personal replies are not guaranteed.
VisualEditor is a way to edit pages that looks more like a word processor. It was first offered here in 2013.
How do I enable VisualEditor?
VisualEditor is available alongside the original wikitext editor if you opt-in, by changing your preferences. It is currently not available to unregistered users at the English Wikipedia, unless they switch modes while editing.
Why is this change being made?
Some people who could become productive, experienced members of the community are turned off upon attempting their first edit in wikitext "source" mode. Some edits, such as adding or rearranging columns to a table in wikitext, are difficult even for experienced editors.
Where do I go to learn more about how to use VisualEditor?
In most cases, VisualEditor will not change or reformat lines that are not being directly edited. If markup already on the page is handled incorrectly (for example, with tables that are not closed), then it may attempt to correct these.
Will it still be possible to edit articles using wikitext after the visual editor becomes available?
Yes. While the visual editor will become available to all users as an editing environment, a method for editing the underlying wikitext "source" will continue to exist. There are no plans to remove the "Edit source" option.[1]
Won't this slow down reading and editing for people who have slow connections or computers?
VisualEditor loads the bulk of its code only when you edit a page in the visual editing mode. So if you keep using "Edit source" or are a reader, the effect on your user experience should be negligible (~4KB of additional JavaScript payload before you click "Edit", or about 0.5% of one typical page). Your web browser will typically cache the JavaScript, speeding up future uses even if you are on a slow connection. However, using the visual editor for editing may cause problems for those on slow computers or connections, especially on very large pages. For these users, opting-out for now may be the best option.
I've found an issue with VisualEditor or a feature that is missing. How can I tell you to fix it?
Please report the issue in Phabricator, after first searching exiting tickets to make sure it hasn't been reported already. Additional bug reporting instructions can be found here. There are four main kinds of issues that the developers especially need to hear about:
Something breaks: The failure may only affect a particular type of browser or computer, on a particular page, or after doing something else. Please post your problem at Wikipedia:VisualEditor/Feedback. In your description, it is helpful to include information about what you were trying to do, your web browser, computer operating system, and a link to the article or a diff of the edit if it was possible for you to save the change.
Performance problems: If all pages seem unexpectedly slow on loading or on performing a particular task, or if it used to be faster and has recently gotten worse, then please report this.
User experience issues: If it didn't make sense, or if it was awkward, or if you couldn't figure out what you needed to do (Wikipedia:VisualEditor/User guide covers the basics), please speak up, and feel free to offer your suggestions for improving the design.
Missing functionality: Is there something you need to do, but it currently can't be done in VisualEditor, like editing mathematics equations or seeing hidden comments that contain instructions to other editors? Make sure that it's on the developers' list of needed features. If you'd like to know which missing features have been reported before, you can search the talk page archives and feedback archives. If you can't find any reference to the new feature you'd like to suggest, please report it at mw:VisualEditor/Feedback.
To continue to edit the wikitext directly, simply click the "Edit source" button instead of "Edit". On section edit links, you can open the wikitext editor selected in your preferences for that section by clicking "edit source" instead of the regular "edit" link.
If you would like to remove VisualEditor from the user interface, then you can do so.
If it is a beta feature: go to the Beta tab of your preferences page, untick the checkbox "Visual Editor", and click the Save button near the bottom of the page. (As of 2021, this is how you do it on Meta-Wiki and the Chinese Wikipedia.)
If the visual editor is already out of beta:
go to the Editing tab of your Preferences page, untick the checkbox "⧼visualeditor-preference-betatempdisable⧽", and click the Save button near the bottom of the page. (This is how you do it on some sister Wikipedias, for instance, Russian Wikipedia, as of 2021.)
Can I install VisualEditor on my personal wiki outside Wikimedia?
Yes. The VisualEditor extension is available for download.
Can I use named references like the basic wikicode editor does, so I can choose my own reference names?
This has been requested via Community feedback, and is on the list of things to do. There are some links and more information about this on the Wikipedia:VisualEditor/Named references page.
The FAQ didn't answer my question. Where may I ask it?
^<<And no, we're not taking markup-level editing away. Some users may always prefer it over visual editing, even if the exact nature of the markup changes, and even if VisualEditor becomes the best tool it can possibly be.>> Erik Möller, deputy director of the Wikimedia Foundation, The VisualEditor Beta and the path to change, op-ed for Wikipedia Signpost, July 31st, 2013.
This is actually not my own experience, but those that I have seen on articles on my watchlist. When someone edits an article, sometimes, for some reason it deletes the whole infobox (and strangely only that, any maintenance tags at the top of the page remain). Sometimes, it even adds a nowiki tag to the article (which is probably related to the long-running bug with nowiki tags), although I can't see any mention of the infobox deletion on any of the current discussions. How can this be solved? Narutolovehinata5tccsdnew23:35, 1 August 2013 (UTC)[reply]
Could you link to some diffs please. I know that there has been at least one bug relating to VE removing templates, but I can't find it at the moment. Thryduulf (talk) 00:01, 2 August 2013 (UTC)[reply]
Technically, this is not a VisualEditor bug. What happens is that the user backspaces one time too many, and since the entire infobox is "one character" in VisualEditor's mind, it gets deleted. If the user doesn't notice and undo the backspace, then it's gone. But while it's not a "bug", it's a problem, and it's already in Bugzilla so that some sort of fix can be devised. (Perhaps you should have to confirm deletion of a template? If you've got ideas, let me know, or add them to the bug report yourself if you've got an account there.) Whatamidoing (WMF) (talk) 00:56, 2 August 2013 (UTC)[reply]
One idea would be to somehow flag the templates where a confirmation step is appropriate, but it'd have to batch up the confirmation if multiple nodes are affected, and maybe have a "Don't show this again" checkbox. Feels unwieldy.--Eloquence*01:28, 2 August 2013 (UTC)[reply]
I personally think confirmation each time a person deletes a template with a "do not show this again" checkbox (which is remembered across edits) would be adequate. As you say, a single user action should trigger at most one warning. I don't find this unwieldly. Dcoetzee02:13, 2 August 2013 (UTC)[reply]
An other way would be to do like Word do for images: the first backspace selects the image, a second one deletes the image. The same kind of behavior could be applied to templates: first select the template, then delete it on a second key stroke. --NicoV(Talk on frwiki)06:19, 2 August 2013 (UTC)[reply]
A confirmation asking for permission each time the error occurs is horrible, and if you click "Don't show this again" it won't protect you, so this solves nothing. Selecting the image on the first backspace is the way to go. Diego Moya (talk) 13:54, 6 August 2013 (UTC)[reply]
I've just made an edit using VisualEditor. In my edit, I merely wikilinked to a person. I did not use backspace, but once again, the infobox was accidentally deleted. And now, it appears that most of the VisualEditor edits on pages on my watchlist are having the same problem (see this and this). Does this need a new Bugzilla entry or should it continue to be tracked under the old one? (I don't have a Bugzilla account). Narutolovehinata5tccsdnew14:59, 3 August 2013 (UTC)[reply]
I'll add to that bug for you, don't worry about this. As for the "getting worst" part, I think this is also related to us having among our watched pages many pages that might suffer from that specific bug. As an example, in the previous days I had to fix some articles on the Italian WP where VE would struggle with an infobox about fictional characters. Each time someone else edited those articles, the "bug" would appear again. Now that we have found a workaround for that and those pages will be ok, I am not going to think "it's gotten better" ;) --Elitre (WMF) (talk) 15:20, 3 August 2013 (UTC)[reply]
I'm seeing this as well. [2] It doesn't seem to be hitting every single edit. What is the suggested workaround, besides going back into the old article and restoring it at the end of the editing session? -AngusWOOF (talk) 16:09, 9 August 2013 (UTC)[reply]
It's not the same it.wp is experiencing. (We had two main issues, turns up the one that was solved was the infobox not allowing VE to load at all). Hopefully the deleted infobox bug will get some love as soon as devs come back from Wikimania. Thanks, --Elitre (WMF) (talk) 16:58, 9 August 2013 (UTC)[reply]
I'm seeing a lot of infobox removals with VE these days. Just one recent example [3] - an editor removed the infobox while editing a section that does not contain that infobox). Materialscientist (talk) 22:03, 10 August 2013 (UTC)[reply]
Every time I make an edit anywhere on that page in VE the infobox gets deleted (I don't save, for obvious reasons). I notice that the infobox there is produced from four templates, which makes me wonder whether what we're seeing is actually Template:Bug caused by Parsoid seeing 4 incomplete tables rather than one complete one? I've added comments to this effect to Template:Bug and marked it as critical. Thryduulf (talk) 23:12, 10 August 2013 (UTC)[reply]
So, I logged out a bit ago and tried to make an edit using the Visual Editor as an anon. Three things surprised me.
The button to use the VE said "edit (beta)". It was to the right of the "edit source" button. I'm concerned that "edit (beta)" doesn't give any indication that it's a more new-editor-friendly (ideally) version. Not sure how to fix this or rephrase it to sound more appealing.
The warning/introductory message that I got immediately after clicking that button didn't fit in the dialog; I couldn't scroll down to read it all. Not sure if anyone else has had that issue.
The edit never showed up as saved; after about three minutes it said "Error: Unknown error" or something similar. Nevertheless, when I opened up the article in another tab, my edit HAD in fact been saved.
Anyway, after all this time, the editor seems to be working way better than before. Still got a long ways to go, but I am impressed and grateful to the development team which has poured so much time and effort into these improvements. Red Slash15:51, 3 August 2013 (UTC)[reply]
Regarding #1, I think that having VE as secondary, marked as "beta", is what we want to do at this point, given the number of problems still existing. Now that this is the secondary link, the more adventuresome - or frustrated - editors will try it, while those who are happy with the wikitext editor won't necessarily bother.
In general, I think it's possible to underestimate the curiosity of Wikipedia editors - at least, of those likely to stick around. Given two different "edit" links, it seems to me that the curious will try them both, and if they like VE, they're more likely to be forgiving (at the moment) preciously because it's marked as beta, and because it isn't being thrust upon them as the preferred link. -- John Broughton(♫♫)04:14, 4 August 2013 (UTC)[reply]
@Red Slash: I think it is probably another example Template:Bug, and I've left comments there. However it would be useful if you could upload a screenshot (see User:Thryduulf/How to upload screenshots of Wikipedia if you don't know how). To see the beta notice again you need to delete the "ve-beta-welcome-dialog" cookie, in Firefox you can do this by selecting the "Preferences" option in the Edit menu, clicking the Privacy icon at the top, then the "Show cookies" button about two thirds of the way down on the right of the dialog box. In the search box of the new dialog type "ve-beta-welcome-dialog" (without quotes or any following spaces), make sure it is selected and then click the "Remove Cookie" button in the bottom left (the one with the red line, not the "Remove all cookies" with the mop). You can then close both the cookies and preferences dialogs. You will see the dialog again next time you load VE. Thryduulf (talk) 08:51, 8 August 2013 (UTC)[reply]
Thank you for that screenshot, it shows that this isn't what I was thinking of. It might be a different manifestation of the same bug or it might be a different one. I'm not awake enough to do anything with it right now but I'll look at it in the morning. Thryduulf (talk) 02:09, 9 August 2013 (UTC)[reply]
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Let's say I want to create a link. I find one with the correct name in the dropdown list, and click on it. There is currently no way to open the Wikipedia link inside the edit page. I have to create a new tab and manually check that the page is really what I want to link to. I think this should be implemented for ease of use. DeathOfBalance (talk) 20:18, 4 August 2013 (UTC)[reply]
Links to technical or obscure pages sometimes fail to list, for example: on Shaft I highlighted "Handle" and "Tang" which produced lists missing Handle (grip) and Tang (weaponry). There still seems to be a problem opening the link while editing (as above) and sometimes (on saved pages) links made with VisualEditor only seem to open if opened in a (right click) "new tab" - personally I think preview might be more relevant than review changes for testing that links work correctly before saving.
Occasionally (not always) VisualEditor hiccups on opening, which the source editor does not, however I think that is because my browser suppresses info-banners such as donation appeals? Otherwise, useful, especially for new users, although personally I find the source editor much more convenient. Regards, Timpo (talk) 11:30, 9 August 2013 (UTC)[reply]
Links not opening on left click is desired behaviour as it stops you losing your edits. When opened in a new tab or window (right click or ctrl+click) they don't suffer this problem (although per Template:Bug they currently don't load the right URL). Template:Bug is a request for previews in the link dialog along the lines of navigation popups, which should solve the preview issue.
Do you mean the "i" icon in the lower right of the template? In what way do you mean it crashes? I've tried editing this in my sandbox, and while the "i" icon is misaligned I've not experienced anything like a crash (Firefox 22/monobook/linux). Thryduulf (talk) 13:30, 8 August 2013 (UTC)[reply]
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)[reply]
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 Template:Bug. Thanks for the report. Thryduulf (talk) 19:23, 8 August 2013 (UTC)[reply]
@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)[reply]
shifting entries in a bulleted list leads to a whole variety of issues. Removing the last item leaves the last bullet. Adding an item at the beginning generated unbelievable wierdness: double bullet at the beginning of that line, added random header text, etc. The up cursor is also frozen. The only solution was to abort the session and edit in source.
To duplicate:
In Education in the United States#Electives, cut the final bullet line and insert it before the first bullet. If the line cut includes the end-of-line, weirdness results. Since it is invisible to the user whether the selected text does or does not include the end-of-line, this is going to be a problem. (I think the problem has to do with the list directly preceding the header of the next section, and something of the header formatting and even text being included, even though not visibly selected.)
I can't reproduce anything of that (Firefox 22/Linux) other than the double bullet. This is because that is how ** is rendered when there is no * on the preceding line. Thryduulf (talk) 09:36, 9 August 2013 (UTC)[reply]
I can't reproduce this reliably either, however I have had similar problems with cut and paste losing formatting, and it depends very precisely on the selection region. You might need to specify down to the individual key stroke how to reproduce it. There are a lot of copy and paste bugs Template:Bug is a tracking bug for some of them and robust behaviour for this is very important.
I have managed to do a cut and paste in this section which does lose all the formatting, but I'm having problems getting it to be reproducible.--Salix (talk): 10:33, 9 August 2013 (UTC)[reply]
To reproduce the error reliably:
edit any bullet list immediately preceding a section header with the visual editor.
Bring the cursor to the beginning of the last bullet.
Holding down the CTRL-key, press the down-cursor key, thereby selecting the entire line plus some part of the following header.
Still holding down the CTRL-key, press the left-cursor key just until the header letters no longer appear as selected.
Cut the selected text and paste it in front of an earlier bullet point (or, probably, anywhere else in the article). Weird results ensue.
Incidentally, as soon as the text is cut, the up-cursor button is disabled.
I believe that the following line's header formatting codes are actually selected but the user cannot see this. Microsoft Word has similar buggy behavior. hgilbert (talk) 11:46, 9 August 2013 (UTC)[reply]
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)[reply]
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)[reply]
See this earlier bug report, now tracked as bug 52271. I've finally figured out what it is that is causing the saved text to differ from what you expect. This is almost certainly the same underlying problem as reported in 52271, but it's somewhat more serious because what is saved is not always what you see on screen.
To reproduce in a sandbox:
Add a template such as {{chem}}; I used 14 C, created by {{chem|14|C}}. Put some text on either side of it so you can copy/paste it with text, since templates won't copy/paste successfully by themselves.
Save that page, and edit again.
Now copy the template and paste it twice, so you have something like this:
-- 14 C -- -- 14 C -- -- 14 C --
Now edit the first pasted one -- the middle one in the example above -- so that it changes a parameter:
-- 14 C -- -- 12 C -- -- 14 C --
Paste again; the pasted version will be 12 C, which is bug 52271.
a) I've seen two different behaviours for the next step. One is that you'll now see this:
-- 14 C -- -- 12 C -- -- 14 C -- -- 12 C --
but when you save the third one will be a 12 -- that is, it will have changed what you see on screen to be different in the saved file.
b) The other behaviour I've seen is that after the final paste, all four of the templates show "12", not "14".
I've added your comments to Template:Bug as it is the same issue, I've also adjusted the bug title to make it clear that the save differs from what is shown to the editor. Thanks, Thryduulf (talk) 10:22, 9 August 2013 (UTC)[reply]
Trade-offs in speed improvements
Hi, as I know some of the most busy VE testers don't really hang around other discussions, I'm here to point to this thread Sherry opened to hear from all users about which type of speed-related improvement is most important to them when they're editing in VisualEditor: speed of operation, or speed of starting? Add your comments there! Thanks, --Elitre (WMF) (talk) 10:23, 9 August 2013 (UTC)[reply]
Not sure whether it was covered before. I was editing Yevgeny Urlashov with VE and at some point got a pop-up message that the article contains wikitext. (Apparently, I must have added the wikitext, though I can not recollect doing so). After the message, the "save" button became unclickable, and there was no way I could save my (rather extensive) edits. There was also no hint at what could contain wikitest, so that I at least could erase and recreate this part.--Ymblanter (talk) 11:02, 9 August 2013 (UTC)[reply]
I've reproduced that on Windows 7, Chrome, in the same article. I deliberately added the word [[test]], so that I would know where the markup was. Even after removing it, I could not click on save, either. --Maggie Dennis (WMF) (talk) 11:13, 9 August 2013 (UTC)[reply]
Okay, it's really weird that I do not encounter the same problem when I do the same thing on a random article (which happened to be Maundy Gregory). I dismissed the error box, and the "save" page button works, although I aborted prior to saving. Technical people, any clue? --Maggie Dennis (WMF) (talk) 11:14, 9 August 2013 (UTC)[reply]
I can't reproduce this at all; the button stays green and responds to being clicked (indeed I managed to save a small edit, although I obviously removed the wikitext before doing so). I tested in both monobook and vector, using Firefox 22/Linux. Are you using Windows Maggie? If so then that's one point of commonality. It would be odd to happen in both Chrome and Firefox on Windows but no other combination though. Thryduulf (talk) 11:37, 9 August 2013 (UTC)[reply]
I did reproduce it again on the same article, now deliberaetly inserting [[test]]. After I click on the pop-up message and remove [[test]], whatever I add, I can not say. The save button stays light green.--Ymblanter (talk) 11:45, 9 August 2013 (UTC)[reply]
I switched to my laptop (Chrome, whatever Mac OS I have there), and it let me save. I tried it again on my desktop and found that if I clicked "save" immediately after dismissing the window, it didn't work. If I persisted, it did after a few seconds. --Maggie Dennis (WMF) (talk) 11:50, 9 August 2013 (UTC)[reply]
I just meant that the button was green as usual: when you can't click on it (happened to me before, should find that bug again) you notice a slightly lighter green. Can this be similar to [4], although there are no bullets in the article? --Elitre (WMF) (talk) 11:53, 9 August 2013 (UTC)[reply]
Well, I don't know about that - you lost your edit because you didn't know. That's still a problem - that shouldn't ever happen. It's just a different problem. :) I'll log it. --Maggie Dennis (WMF) (talk) 12:04, 9 August 2013 (UTC)[reply]
Maybe related to the above wikitext problem, but i don't want to mix issues. The "Cancel" and "Save" button are not properly handled after the wikitext warning message is displayed. Error can be reproduced.
Check the green button, after entering edit mode. The whole area of the button is clickable - OK.
Let the wikitext message pop up with some wikitext addition. Now the buttons are "locked", you can hover over the visible parts of them, but they are not clickable - OK.
Remove the warning message with a click, no need to change anything else.
Hover over the "save" button with your mouse again and check, where it's clickable. Its upper third and the right corner are still "locked" ("Cancel" is also only partially clickable) - not OK, buttons should be fully released.
Those partial locks are only released, after you clear your browser cache (stopping VE is not enough) - not OK.
Sorry for the lengthy desciption, but it's a bit difficult to explain that :). Using Windows XP, FF 22, vector.js and a 1280 x 1024 resolution for test. GermanJoe (talk) 12:29, 9 August 2013 (UTC)[reply]
I was able to reproduce this. When I hover over the upper part of each button, the cursor does not change. I'd add that this behavior changes if you zoom in or out (that is, if the buttons get bigger or smaller). Is this something which might be added to the bug above? Thanks, --Elitre (WMF) (talk) 12:37, 9 August 2013 (UTC)[reply]
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)[reply]
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)[reply]
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.
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Procedure: Using Windows Vista, press Shift + Alt + Print Screen to activate "high contrast" mode. Open VE in Firefox. Weep uncontrollably (see screenshot).
It is worth noting that, when using the high contrast extension for Chrome, the interface is fully visible in every setting. Hooray! --Cryptic C62 · Talk16:12, 9 August 2013 (UTC)[reply]
Ouch! I've reported this as Template:Bug and set the severity to "critical". XFCE doesn't have a high contras mode in the same way so I can't directly test it (it does work in the "high contrast inverse" theme but that's nowhere near as black as the windows one), but that screenshot says it all. Thryduulf (talk) 17:18, 9 August 2013 (UTC)[reply]
Seems like it is stripping background images. We already had accessibility issues here, but stripping the images makes it more visible to other users I guess :D —TheDJ (talk • contribs) 19:06, 9 August 2013 (UTC)[reply]
You'll find out it is not a software, nothing was installed. If you can provide details so that we can understand why it won't work for you and look for solutions, we'd be glad to hear them. Thanks :) --Elitre (WMF) (talk) 14:57, 10 August 2013 (UTC)[reply]
Autocorrect Bug
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)[reply]
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)[reply]
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)[reply]
Keyboard shortcut to show the changes does not work any more
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)[reply]
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)[reply]
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)[reply]
When editing html comments should be visible
The following discussion is marked as answered. If you have a new comment, place it just below the box.
Html comments are an easy way for information to be left for future editors, and anyway they should be shown for backward compatibility. Mark Hurd (talk) 19:13, 10 August 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Yes, I was just thinking the same - a message explaining how to edit references would probably help. I've filed Template:Bug 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)[reply]
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)[reply]
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)[reply]
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 Template:Bug.--Salix (talk): 08:53, 12 August 2013 (UTC)[reply]
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)[reply]
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 Template:Bug, 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)[reply]
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)[reply]
A good suggestion that I've added to Template:Bug, 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)[reply]
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 ([5]), 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)[reply]
as a newbie using freindly interface, I would prefer this to be automatic
Template:Bug 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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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 can't reproduce that in my sandbox using the latest firefox (23) on linux [9] (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)[reply]
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.
Template:Bug 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)[reply]
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 [11]. 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Template:Bug 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)[reply]
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)[reply]
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
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)[reply]
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)[reply]
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. Template:Bug 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Now at [13]. 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)[reply]
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 Template:Bug, 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)[reply]
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)[reply]
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)[reply]
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)[reply]
Warning if editing a reference that is used multiple times
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)[reply]
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.
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)[reply]
Increase loading and performance speed please.
This is very important. Loading the source is still faster. Thanks.
Red Slash 01:50, 9 August 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)
