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.
When editting a file page on Commons, the VE has trouble with the capitals of the template "Information". VE introduces new empty lines, such as | description = and | source while | Description = and | Source are already present. See this example: https://commons.wikimedia.org/w/index.php?title=File:Snelle-1557695721.jpeg&diff=350674224&oldid=350674153
Perhaps this can be corrected. Kind regards, Ellywa
I believe this is tracked in Phabricator task T179259. A lot of editors have been complaining about this since at least 2017. You can add a post in Phabricator if you think the Foundation needs to work on this, or you have anything else to contribute.
However thus far it appears that the Foundation just plain doesn't want to fix it. Some staff have actually asserted that this is deliberate and desirable behavior for VisualEditor.
Thanks, in that case it is useless to mention this in Phabricator, but if you think it is useful, please copy/paste my text. I barely use the VE in Commons, only this time, so I am having an easy workaround.
actually this is mostly because people have been messing about with the TemplateData of the information template on Commons. I'm inquiring the editors what their intent was.
This is not T179259. Those minor whitespace changes exactly follow the format (recently) specified in TemplateData.
The problem is that no template should have both the original |Description= and its more common alias, |description=, present. TheDJ, are you closer to having enough information to file a bug report?
Visual Editor is generating disruptive dirty diffs modifying parts of the page that the user did not touch. Whether those dirty diffs are additions or removals is immaterial. I believe the issue here will be resolved by T179259. If you believe that fixing T179259 will not fix the bug reported here, then please update T179259 to cover this case or open a new task.
i'm not sure when i can follow up on this, i'm super busy at work and in personal life. Some changes were made, some things were fixed, but i can't verify any of it right now, nor work on further fixes.
On many wikis, directly inserting the magic word __DISAMBIG__ (or equivalent) is undesirable, a template is to be used instead. Can the disambiguation page tick box (Visualeditor-dialog-meta-settings-disambiguation-label) be disabled or customized to insert something else?
What's the practical purpose for preferring a local template to core MediaWiki magic words?
What's the practical purpose for inviting users to violate local policy? The wiki communities get to decide what a disambiguation page is supposed to look like. When direct insertion of the magic word is undesirable, the tick box is a pitfall.
My question is why any community would decide that using MediaWiki's native wikitext markup is actually "a violation of local policy". I can understand "Eh, I'm used to templates, and I run AWB, so I auto-replace this code with a template, just because I like it that way, and I can", but why would you make something (IMO) so unimportant a matter of "violating local policy"?
Firstly, I wouldn't classify __DISAMBIG__ as a "core MediaWiki magic word" since it requires an optional extension. So a local template would make turning off the extension more practical.
Perhaps "violating local policy" was too strongly worded. But it's not like you describe. Disambiguation templates already existed as standard practice on hundreds of WMF and non-WMF wikis when the extension was introduced in 2013. The templates generally inform the reader about the purpose of the page and track them in a category. And after installing the extension, these templates are generally modified to also transclude the magic word. So the primary way of marking a page as a disambiguation page is via the template.
Based on the conversation last year at T187116 (which is a much smaller request than your idea), I'm doubtful that we'll see any progress on anything related to this.
As a more immediately accessible workaround, it's theoretically possible for a local admin to add some additional information to MediaWiki:Visualeditor-dialog-meta-settings-disambiguation-label. In English, that message current says "This is a disambiguation page", and perhaps you might like it to say something like "Mark this page as a disambiguation page without adding any explanation for the reader. (Note: This wiki normally inserts Template:Disambiguation instead of using this option.)"
I thought about changing the label before starting this thread, but since in my opinion this tick box should probably never have been added in the first place, I hoped there was an option to disable it.
Hi
I have an idea to write a bot that can fix lint errors in all Wikimedia sites. Writing a bot from the beginning is very time-wasting. And need to be tested for a long time. Many other Wikimedia sites still have thousands of pages that need to fix the lint errors as fast as possible (High priority).
By chance, I notice that if we use visual editor parsoid API services, to convert the wikitext of a page to html, then using the same API to convert the html generated to wikitext again, it will fix most of lint errors inside the page. Since parsoid fix html errors when trying to convert to wikitextx using this API
https://www.mediawiki.org/api/rest_v1/#/Transforms/post_transform_html_to_wikitext
The problem is that there is an option called "scrub_wikitext" that make some cosmetics, and normalizations to the wikitext generated. I tried to disable this option each time, but it keep making the normalizations.
Is there a way to convert from html to wikitext without making normalizations and in the same time fixing the html errors?. If this is possible, it can be very very helpful globally. Thanks.
Pinging @SSastry (WMF), @علاء, @NicoV, and @Izno: This editor has some ideas for a de-linting bot.
@ASammour So, to prevent normalizations, you need to trigger selective serialization mode. See https://www.mediawiki.org/api/rest_v1/#/Transforms/post_transform_html_to_wikitext See the documentation there at the top about preserving syntactic variations. You need to pass in all those parameters with your post request. Additionally, see https://www.mediawiki.org/api/rest_v1/#/Page%20content/getFormatRevision .. If you intend to fetch the HTML to edit it and post it for save, you should pass the "?stash=true" parameter in your get request.
Actually scratch my comment. If you don't make any edits to the page, selective serializer will preserve the wikitext as is .. and if you fix one lint error, it will only make changes to that fix and not fix anything else on that page. You are trying to trigger fixing of *all* linter errors on the page by saving it.
So, unfortunately, no there isn't a way to get Parsoid to only fix lint errors and leave everything untouched. It will normalize syntax and whitespace and quotes, etc.
Also, a general comment about auto-fixing. Not all lint errors can be auto-fixed by a bot. Some fixes will require human intervention.
Hej, jag försöker ta bort felaktig infomation i artikeln men det sparas inte, artikeln kommer tillbaka till den versionen jag försökte ändra.
URL: https://sv.wikipedia.org/wiki/Transcendental_meditation?veaction=edit
According to the page history, your changes were published, and then @Yger and @Adville reverted your changes. You should talk to them.
Is there some reason why VE is not enabled in Wikiversity:Draft: space? It would be very useful to have it available there. I currently develop drafts in User: space for this reason. However I have noticed that conversely there are some display features which are available in Draft: space but not in User: space, in particular Reference tooltips work in Draft: but not in a User: page. I am working on a draft of a resource that employs many footnotes designed to be viewed quickly as mouse-fly-over Reference tooltips, but testing them in User: space isn't possible.
Well...
The answer to your direct question is that it doesn't work because it wasn't enabled, and that could be changed. Ideally, you (or someone) would hold an official discussion in which that community agrees that it would be a good idea, etc., and then we file a request in Phabricator. (Filing the request is easy; one of us just copies something like T126561 or T223024, and then we wait for either a volunteer or staff dev to process it. The point of the discussion is to prevent someone from adding a #community-consensus-needed tag, and thus getting the Phab task delayed.)
The thing I think you might want to consider is: Should Wikiversity have a Draft: space at all? The research I've heard about suggests that it's where pages go to die, and if you're serious about building content, it's much better to have that content in the mainspace. (This research was done by the same people who originally proposed Draft: space at the English Wikipedia, and they are no longer as enthusiastic as they used to be.)
Yes, I think you're right that perhaps the Wikiversity Draft: space isn't a good place to populate after all. Developing content in the Wikiversity mainspace solves both the problems I mentioned, because both VE and Reference tooltips work there. That said, there will still be drafts in User: space. Do you know why Reference tooltips don't work in User: space? I think I'd like to follow the discussion/request route you suggest to get that enabled (in WIkiversity:User:, not WIkipedia:User:), if there isn't some reason it shouldn't be.
I don't know why the Reference Tooltips feature doesn't work in userpsace. (Shouldn't it work everywhere?) If you're running the same gadget, then @Yair rand is probably the best person to ask.
Hello, since few weeks a lot of Arabic Wikipedia users are asking about using of VisualEditor in Wikipedia: namespace, but I replied that (VisualEditor is only enabled for some namespaces. At most Wikipedias, VisualEditor can be used on articles, User:, File:, Help: and Category: pages. VisualEditor is not currently available for Wikipedia: pages or any talk pages.)
So, is there any steps to enable it in Wikipedia: namespace on arwiki? if not, is there any way to do that?
The usual thing to do is:
Note that the team believes that the visual editor is not well-suited for very busy discussion pages. Also, it does not support using : to "indent" replies.
Issue:
As a user , I'd like to see meaningful descriptions when searching for files.
Steps to reproduce
Expected
File:李鐵夫孫中山12345.jpg contains an applicable caption, "Sun Yat-sen" (based on user language as found in https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=wbgetentities&format=json&ids=M73856135
).
Actual
File:李鐵夫孫中山12345.jpg is found in the list of files.
URL: https://ca.wikipedia.org/w/index.php?title=Usuari:Ares_Vald%C3%A9s_Dom%C3%ADnguez/proves&action=edit
Hola, estic creant una pàgina amb el títol Ángeles Ribes Duarte. I no vull que surti com a títol Usuari: Ares Valdés Domínguez/proves. Com puc fer-ho? Gràcies Ares
Hola, Ares. Una vegada hagis acabat de polir l'article, usa l'opció de la barra de dalt Més/Reanomena posant com a nou títol primer l'espai "(Principal)" i a continuació el títol de l'article. Si tens cap problema amb aquesta operació pots demanar ajuda a ca:Viquipèdia:La taverna/Ajuda i algun altre usuari ho pot fer per tu.
When browsing through the various documentation pages, it seems as if development has been suspended two years ago. Sorry for the maybe silly question, but what is the current status of the VE? Are there plans for relaunching and further development? Or am I completely wrong and the VE is alive and healthy, just the documentation a little bit outdated?
What exactly makes you think that development has been suspended? :) Documentation updates are welcome if you find something outdated!
It's just what I am worrying about when viewing ...
and so on. It is all a little bit difficult to understand for s.o. outside the WMF and/or developer team.
I might be completely wrong - alright then, the better. We are just a small private wiki and have installed the VE (which is "still experimental" for outside Wikimedia, as I read) to launch for a usability test. I would not appreciate investing time in testing and asking for support, if I'll hear it will be ceased afterwards. On the other hand, outdated pages might be a manpower bottleneck just the same as with our contributors ...
Finally, the Talk pages consultation 2019 and look to me as if there were bigger problems the WMF has to deal with, than some minor VE bugs and requests.
VE (which is "still experimental" for outside Wikimedia, as I read)
Correct. The Foundation's budget priorities don't align with us making the epic re-engineering of VE into a state that it's as easy to install as the rest of the MediaWiki, and so it would be irresponsible for us to recommend it to low-end third party users.
Note that there's no-one who is paid by the Foundation to provide support to anyone for any part of MediaWiki, core or extensions, let alone VE. The support that do people get is generally either staff working in their personal time, or other members of our wonderful developer community, both volunteers and those paid by other organisations.
To help the team out, I have updated the three old status systems to explain to people that the are obsolete , noted that there aren't any VE-specific engineering update systems any more , and removed the reference to when the 2017 editor's integration last changed . Thanks for spotting the issues, and sorry it caused you concern!
I do not use the visual editor myself but just noted that this good-faith edit which was tagged as visual edit flooded an entire Wikipedia article with inappropriate <span dir="rtl" lang="ta">...</span> constructs.
User error (or user malice). He did "select all" and then chose Formatting -> Language -> Tamil from the menu.
I've seen that a couple of times before. I have always assumed that the user was hoping innocently for a translation of the article.
Perhaps it could be helpful if the visual editor would be more reluctant to update an entire page this way. The problem is that such updates are not immediately noticed and the fix causes quite some work if a series of regular edits follows. (In the example above the edit lasted for one and a half year until I fixed it.)
