VisualEditor/Feedback

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)

Previous page history was archived for backup purposes at VisualEditor/Feedback/LQT Archive 1 on 2015-07-30.

$F_{s(m)}={\frac {\sum [c'b+(W-ub)\tan \phi ']/m_{\alpha }}{\sum W\sin \alpha }}$

$m_{\alpha }=\cos \alpha \left(1+\tan \alpha {\frac {\tan \phi '}{F_{s}}}\right)$

Why : work as blockquote? I can write like above with source editor, but I can't do the same with visual editor. It looks odd when I have a look at the next equations.

$F_{s(m)}={\frac {\sum [c'b+(W-ub)\tan \phi ']/m_{\alpha }}{\sum W\sin \alpha }}$

$m_{\alpha }=\cos \alpha \left(1+\tan \alpha {\frac {\tan \phi '}{F_{s}}}\right)$

It's much stranger in the mobile version when I write like this.

blahblah blah blah. The equation is

$F_{s(m)}={\frac {\sum [c'b+(W-ub)\tan \phi ']/m_{\alpha }}{\sum W\sin \alpha }}$

$m_{\alpha }=\cos \alpha \left(1+\tan \alpha {\frac {\tan \phi '}{F_{s}}}\right)$

The : code, when used by itself, produces invalid HTML. The : dos not mean "indent". It means "mark this as the second half of an HTML definition list". Therefore, it should be used to make lists like the ones in w:en:Disease#Terminology, but not to manipulate the visual appearance.

Math editors have talked about fixing sitewide CSS to solve that problem, but I don't remember what the ultimate advice was. @Physikerwelt might be able to point you in the correct direction.

@Whatamidoing (WMF) I have not followed up the recent developments. To my understanding the German math community decided to write

:<math

rather than

<math display=block

. As an extension developer, I would recommend useing the built-in mechanism

<math display=block

. But this is biased. It looks like this on many wikis.

$$a+b$$

On enwiki, where the community decided to accept this encoding it looks almost identical to the : way.

https://en.wikipedia.org/wiki/Help:Displaying_a_formula#Display_attribute

Disclaimer: I do not understand why : is invalid HTML. It is wikitext. Invalid wikitext is to me not a good argument to justify a wikitext parser that generates invalid HTML. That sounds more like a bug in the wikitext parser.

; and : are defined in wikitext as producing the first and second parts of a definition list. Therefore, if you start a line with either of those characters, the parser will dutifully generate <dt> and <dd> tags around that line, because that's what you told it to do. Unfortunately, there is no "just slide this text over about a centimeter" code in wikitext.

وكيل المستخدم: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

مسار: https://ar.wikipedia.org/w/index.php?title=%D9%85%D8%AA%D8%AD%D9%83%D9%85_%D8%B0%D8%A7%D9%83%D8%B1%D8%A9&action=edit&redlink=1

Erabiltzaile agentea: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

URL: https://eu.wikipedia.org/w/index.php?title=Santa_Ana,_Ama_Birjina_eta_Haurra&action=edit&redlink=1

Nola jarri dezaket beste wikipediako argazki bat ez bada neria baina askea bada? botoiari sakatzen diot edo beste gauza bat egin behar da?

Kaixo Paune, Ez dakit nola heldu zaren hona galdetzera... artikuluan sakatu "Aldatu" botoia eta bertan duzu "Txertatu" > "Multimedia fitxategiak". Irudiaren izena jarri eta kitto.

Hala ere, suposatzen dut ikastaro bateko ikaslea zarela. Kasu horretan banatu zitzaizuen liburuxka urdinean eta berdean, bietan, duzu azalpena. Ez badituzu, eu:Atari:Hezkuntza/Ikasle-gela orrialdean duzu laguntza guztia.

@Xabier Cañas, @Theklan:

Maybe this new contributor is looking for c:Special:UploadWizard?

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.

Thanks

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.

The primary problem here is that the parameter name aliases were broken (description vs Description). That is a template issue on doc. Yes there is also an issue with white space changes, but it is not the issue that is primarily botheringEllywa

Yeah, see: https://commons.wikimedia.org/wiki/User_talk:Kaldari#templatedata

Is the bug actually in that local module?

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.

I was undoing a change to an article, and wanted to add a reference using the VisualEditor, but VE loaded the last version of the article, rather than the edit I was trying to restore. Is it possible to change this behaviour? It is rather confusing to see this.

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.

Användaragent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8

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:

1. Have a discussion at your local Wikipedia (maybe at the village pump or café) about whether editors want to do this.
2. File a request on Phabricator, similar to T158763 or T164435.
3. Wait until it happens.

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.