Post your feedback about using the visual editor.
If you have never provided feedback before, you can learn how to do it effectively. If you are reporting a problem directly on this page, please include your web browser, computer operating system, and wiki skin (usually Vector, sometimes Monobook). The feedback tool within the visual editor will include your user agent details instead.
You can use this page to tell the Wikimedia developers your ideas and issues about using the visual editor: this is the only feedback page actively monitored by WMF staff. The Contributors team welcomes your feedback and ideas, especially on user interface decisions and the priorities for adding new features. All comments are read, in any language, but personal replies are not guaranteed: the team will try and go through reports here at least once a week. Need more attention? Report directly in Phabricator. Please note that the Wikimedia Foundation does not provide support for installing VisualEditor on third-party wikis. Please report bugs involving Parsoid at Talk:Parsoid instead.
You may also want to read a guide to optimize the visual editor's experience on your site, which details work necessary on the community side (such as translating or setting up citation systems).
View open developer tasks – Report a new bug in Phabricator – Join the IRC channel – Test the visual editor! (no account required)
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.
There is a problem, very frequent at least in the french Wikipedia, where the first paragraph of the intro "fuses" with the infobox if you use the Visual Editor.
See this example: https://fr.wikipedia.org/w/index.php?diff=147963144 (edit link: https://fr.wikipedia.org/w/index.php?title=Tintin_au_pays_des_Soviets&oldid=147961827&veaction=edit).
Thank you for your work.
Are you concerned about what readers see in the article, or about what the wikitext looks like in the editing box?
I'm concerned about the text acting weirdly in visual editing mode. Try to hover your mouse over the first sentence:
"Tintin au pays des Soviets (titre complet sur la couverture : Les Aventures de Tintin, reporter du « Petit Vingtième », au pays des Soviets) est le premier album de la série de bande dessinée Les Aventures de Tintin, créée par Hergé, dessinateur belge" in this example: https://fr.wikipedia.org/w/index.php?title=Tintin_au_pays_des_Soviets&oldid=147961827&veaction=edit.
The problem, affecting the editing (fluidity or accessibility), should appear clearly.
As you can see here, I dodged the problem by adding a lane between the end of the infobox and the beginning of the article's intro.
Confirmed, it's bugged when I try it. In the link above, in VisualEdit mode, it does not appear possible to directly edit the lead sentence. Trying to click on that sentence is treated as a click on the infobox. As a bizarre workaround, if you edit the infobox you can scroll down to see&edit the lead sentence in the infobox's "Content" field.
It's the dreaded Complex Transclusion dialog box.
Braaark, do you find that this happens consistently with certain infoboxes, but not with others? For example, I can trigger the bug with Modèle:Infobox Cinéma (film) but not with Modèle:Infobox Organisation.
Yes, that happens consistently with certain infoboxes like:
* for books (Infobox Livre), * for albums (Infobox Musique (œuvre)), * for journals (Infobox Revue), * for films (Infobox Cinéma (film)), * for comic book titles (Infobox Comic book) * and for comic strips (Infobox Bande dessinée)
(those are the involved infoboxes I noticed so far, all from the french Wikipedia).
Click Insert -> Media.
Then click "Cancel" without any operation.
You will find the page cannot be edited
Whenever I remove a field while editing a template, the box scrolls all the way to the top, meaning if I want to delete multiple fields, I have to repeatedly scroll down, press delete, then scroll back down again because it decided to scroll up automatically, click in the next field, delete, scroll down again, etc. It's been a bug for several months, I'm currently using Chrome 66 on macOS 10.13 but it has happened for several versions of Chrome prior to 66. It wastes a lot of time and makes editing very difficult when I'm trying to remove blank parameters left in templates that don't need to be (or can't be) filled, especially in reference templates.
Not a tech issue.
URL : https://fr.wikipedia.org/wiki/Chemin_de_fer_du_Bocq?veaction=edit
Le nom de notre ligne n'est pas : " Chemin de fer du Bocq " mais " Le Chemin de Fer du Bocq"
For me, one of the greatest benefits of the VisualEditor has been the "Cite" button; previously, I found citing my sources to be a very tedious task, and I often just included inline links to cited websites for other editors to clean up, rather than create properly formatted citations. With the Cite button, I'm able to very quickly create appropriate citations. However, the Cite button creates all citations using the yyyy-mm-dd format, while some articles possess templates specifying the use of different date formats, such as mdy or dmy. Could the Cite button's functionality be enhanced to detect such templates if present, and use the corresponding date format?
That's unfortunately not feasible.
It might be possible for the CS1 modules to detect date-formatting templates, and then adjust all of the date formats in an article accordingly, but, in the meantime, you can add the "df" parameter to each template, and then set it to dmy for dmy articles or mdy for mdy articles, and that will do the trick when you save. @Trappist the monk is always the person to ask about what the CS1 modules can do.
You know, I just hate this editor. Tapping the escape key should not irrevocably abandon previous edits. Now I have to write it all over again.
We tried reading article source looking for {{use dmy dates}}. If found we would adjust cs1|2 date rendering accordingly. Worked as I recall for relatively few cs1|2 templates in an article but did not work in articles with large numbers of cs1|2 templates. The discussion about that is here: en:Help talk:Citation Style 1/Archive 10#Automatic ISO conversion. That conversation is where we developed |df=.
Thanks for the note.
I think that @Trizek (WMF) handles Flow bugs these days. When I press Esc, I get a "Do you really want to destroy everything?" kind of question first, which I can then cancel. If that's not appearing for you, then please remind me about your browser/OS information, and we'll see if it can be fixed.
@Whatamidoing (WMF) has listed the correct behavior of structured discussions, which is exactly the same as on the visual editor: there is a warning message saying "do you want to irremediably discard your changes" or something similar when you hit Esc. I've tried it and get it.
@Whatamidoing (WMF), can you fill a ticket if there is any bug? Thanks.
Yeah, I've seen that warning prompt. I was in some menu at the time and a single escape abandoned the whole edit. Don't remember what that menu selection was.
Thanks. That goes somewhat beyond my knowledge of markup, so I guess I'll just leave it for the cleanup bots, which seem to be handling it well already.
Open a page for editing. Place the cursor in the text. Click Insert > Media.
Try typing various beginnings of sensible search term snippets in the search field without hitting Enter, for instance "ark" (which should match names containing the word "Arkansas", among other things).
Sometimes the "throbber" (progress indicator) first appears during typing, and then relevant matches are shown. But sometimes the throbber is not shown, and no results either, but only the text "No results found.", although there are certainly lots of media with names matching the text snippet currently in the text box.
You will have to try this out yourself a few times, with different text snippets, because the behaviour is erratic and random. I have a suspicion the severity of the problem is related to the quality of the Internet connection used, but I haven't been able to verify this.
(Safari 11.0.3)
I found that if I add another letter to the search term (maybe backspace over the last letter and re-type it), it re-searches for me. Does that work for you?
Yes, this is still happening.
Adding another letter, or hitting backspace often makes it re-search. This re-search can either result in "No results found." (although there might be search suggestions in next attempt with the same letters) or search suggestions.
The problem seems somehow to depend upon the time interval between keystrokes. If I type very slowly (one keystroke in every 3 seconds), then there is always new search suggestions for each added letter. If I type faster, it sometimes gets stuck showing "No results found." although the same letters do produce search suggestions when typed at a slow rate.
(Same problem in Firefox 59.0.2 and Safari 11.1)
Would you mind looking over https://phabricator.wikimedia.org/T182014 and telling me if that sounds familiar?
I think it could be different symptoms of the same underlying problem: Whether you get any search suggestions or not depends upon how and at what speed the text is entered into the search field.
Let me add: Other search fields on Wikipedia, Wikimedia Commons etc do not behave this way.
URL: https://es.wikipedia.org/w/index.php?title=Usuario:77.224.107.132/Taller&veaction=edit&oldid=0
@BEATRIZ CAVIA, I'm gonna need more details. How_to_report_a_bug/es should guide you with that.
@ΜάκηςΚεφαλονίτης, I believe this operation isn't currently possible in the visual editor, only in the wikitext one.
@Az313 do you still have the issue? I see the page has actually been created, and then deleted according to rules explained at https://ar.wikipedia.org/wiki/ويكيبيديا:معايير_السير_الشخصية .
URL: https://sv.wikipedia.org/wiki/Nora_Rignell?veaction=edit§ion=2
You are probably being blocked by Commons. Please go to https://commons.wikimedia.org/wiki/Special:Upload or https://commons.wikimedia.org/wiki/Special:UploadWizard and try again.
