2017 wikitext editor/Feedback

Post your feedback about using the first iteration of the 2017 wikitext editor as a Beta Feature. While you can disable it by unchecking the New wikitext mode checkbox in your Preferences (Beta tab), 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. You can learn how to structure well your submission.

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). Also, while editing to reproduce a problem, please try to append &safemode=1 at the end of the URL; if the problem disappears, you are using a gadget or script that interferes with the editor.

We are trying to keep the page tidy by providing links to relevant tasks while closing threads. You can help by adding {{tracked|T######}}. By all means, feel free to re-open a thread if you need to!

See also:

View open developer tasks – Complete workboard – Report a new bug in Phabricator – Join the IRC channel

The current version does not allow null edits. Is this intentional? Thank you.

Yes, "null edits" shouldn't ever be needed.

wikipedia:Wikipedia:Purge#Null edit

Apparently, there are reasons to do so.

We use'em all the time.

The instruction from the Performance team is to file a bug if you find a situation where you think you need a null edit.

 Done title changed to officially list this as a bug report on the official 2017 wikitext editor/Feedback page.

I wasn't necessarily reporting it as a bug, though, just asking to clarify if that was an intentional design choice.

You are kidding?

@IKhitron, I could be mistaken, but I believe JDF is the one primarily responsible for accepting/rejecting issues in this area. For example the lack of a directly accessible preview button, dysfunctional CTRL-V paste paste behavior, faulty previews, etc etc etc.

You are mistaken, in this and other things.

It seems we have a lot in common.

Absolutely. I'm talking about null edits.

Hello, I would appreciate the option to turn off animations (for dialog boxes, etc.) in the 2017 wikitext editor. The animations slow down editing slightly, and more importantly, they make the editor feel less responsive.

Can you tell me what kind of computer you're using?

I've tried the 2017 wikitext editor in desktop browsers on different desktop and laptop computers across Windows, macOS, and Linux. The behavior is the same on every platform. The animations aren't a major performance issue, since they take less than a second. However, the 2017 wikitext editor is already slower than the existing wikitext editor, and these animations make the interface feel even slower (especially for editors who are used to the existing wikitext editor). It's a perception issue, and I think it might discourage editors from adopting the 2017 wikitext editor.

To clarify, I'm referring to the animation of the display of the "Find and replace" panel, the "Special character" panel, and the "Options" dialog box. In contrast, the display of the "Link", "Cite", and "Help" tooltips feel more responsive because they are not animated.

@JKlein (WMF): I think this discussion might interest you.

Our animations take 250ms, and help users keep oriented when the interface changes dramatically. Almost all of our transitions are implemented in CSS, which means the browser only updates during spare CPU cycles, so it shouldn't negatively affect actual performance.

Animations are built into our user interface library OOUI in many places in the JavaScript and CSS, so turning making them optional would unfortunately be an extremely complex undertaking.

Okay, I understand. Thanks for your consideration.

I'm not able to find the menu to insert special characters that used to be at the bottom of the old wikisource editor. Does anyone know this feature is there? If not, will it be added?

Tracked in Phabricator
Task T217857

Why do we not have a "old editor" option? VisualEditor and 2017 wikitext is nice but i would like to be able to switch back to the old editor at times.

You can get an old wikitext editor (in between edits) by hand-editing the URL to say action=submit instead of action=edit or veaction=editsource (or similar bits).

I'm curious when you want an old wikitext editor. What's easier there?

Thanks for the info. Its not that the old editor is easier but it is more responsive and takes much less time to load compared to parsoid. The old editor still has some advantages. Nevertheless, the new editor is cool.(I would still like to see a ui buton for switching to the old editor)

I filed the feature request. The theory is that switching modes while using the same toolbar should generally be faster than opening a different wikitext editor. However, on long/complex pages (or in particular circumstances; some people have old computers or poor internet connections), that might not be true.

Its not that the old editor is easier but it is more responsive and takes much less time to load compared to parsoid.

@Erentar2002 Thanks, what pages do you find take longer to load? In our analysis the new editor is quicker to load in over 80% of cases. Also the new editor doesn't really use Parsoid, except when you use some advanced tools from the toolbar.

I have detected a bug. I cannot edit category pages when I click on edit code: the wikitext does not appear. To be able to edit it, I have to do a workaround: click on edit(visual mode) and then return to edit code and it works.

Ubuntu with Chrome 72 and Firefox 65.

Tracked in Phabricator
Task T153306

Please include a "preview" button next to the "save changes" ("Änderungen veröffentlichen")-button! It's nice that the program kindly reminds me to do so after I hit the save-button and for newbies, which would probably not use the preview-button at all it is fine, but as a user who is used to the old editor I got panic as it looked like I had only the option to save the changes without a previev :) --~~~~

Yeah, a preview button before the "save changes" button would be nice. I would really like not to have to click save changes to preview my changes

I agree.

This 2017 wikitext editor has its good points, but speed is not one of them. A solution is a quick-launch editing toolbar, similar in principle to the quick-launch taskbar in Windows. People choose a few single-click commands. 5 or 6, for example.

The 5 main things I do all the time take 2 clicks or more in the 2017 wikitext editor.

Whereas in the old 2006 wikitext toolbar, etc. they are all one-click tasks (not buried in menus, and no popup intermediaries):

• Bold
• Italics
• Internal link (adds double brackets)
• External link (adds single brackets)
• Signature

A customizable wikitext editing toolbar section would allow people to choose. No one would be imposing their choices.

These could all be added to VisualEditor/Special characters, which stays open, if you can convince your community that they are generally needed.

I wasn't clear in my original title. I just added "personally" to the title.

I did mention in my original post: "A customizable wikitext editing toolbar section would allow people to choose. No one would be imposing their choices."

Firefox browser lets one customize the top bar by adding, removing, and moving around the icons and buttons up there. Maybe developers here could adapt some of their ideas.

VisualEditor/Special characters might work if it had a personally customizable row. But it would only work if it stayed open even after logging out and coming back. It would have to work like a gadget and not depend on cookies for that row to stay open. And I would need only that row to stay open. The other rows take up almost all the remaining space in the edit window.

Why is there no talk page just for VisualEditor/Special characters? The talk page tab Talk:VisualEditor/Special characters goes to a general Visual Editor talk page. That is very poor design.

*Talk:VisualEditor/Special characters redirects to

*Talk:VisualEditor

Some more hot buttons I would want in that always-open row or toolbar:

*Show preview

*Show changes

*Publish now (no edit summary or preview. For my sandboxes).

phab:T136152 is about making it easier to add your own personal buttons. You can do it now, if you want, but it's not the easiest thing to do.

(We unify talk pages to increase the odds that you'll get an answer. Scattered talk pages result in overlooked questions.)

Toolbar needs to be simple. I want it for wikitext editor mainly.

We need both:

1. We need MediaWiki to copy comments from various talk pages, and then paste them (or just their titles) to several central talk pages, and/or to lists of comment titles.
2. And we need the comments to stay on the original talk pages. Improvement often happens from collaboration on talk pages concerning specific topics.

Was most of this meant to be posted to the Talk:Talk pages consultation 2019?

Thanks for the link. I may never get around to participating in that thread, though. Who knows. Feel free to share my ideas. I am probably not the first with the ideas.

I'm on mobile if that helps. Ok so on https://en.m.wikipedia.org/wiki/Draft:RPG_Limit_Break I accidentally paragraphed a T by itself and when I go to fix it, it moves my line where the text goes before the T without me doing anything but hitting the back button. And when I hit publish only the T is there. Not sure if that's because of you guys or not, but when I uncheck the box in beta features and click save, doesn't actually save it and I tried changing it a couple of times. Sorry if this doesn't affect you at all HaiZebrazach20062 (talk) 21:52, 24 February 2019 (UTC)

I helped clean up the specific edit. It looks like this was a mobile VisualEdit rather than a 2017Wikitext edit, so I'm not sure it's relevant on the 2017 feedback board. I'm not sure, but VisualEditor might have misbehaved because the infobox somehow got embedded in the middle of the lead paragraph. I don't think VisualEditor likes it when infoboxes get concatenated with surrounding plaintext.

Tracked in Phabricator
Task T217084

It seems like I CAN NOT choose my editor version by simply changing my URL links.

For example, when I request ...?action=edit with "New wikitext mode" checked, I go to the new version....?veaction=editsource...?veaction=editsource&venoscript=1 also go to new version.

But when "New mode" unchecked, links over lead to traditional/view_page/view_page. But ...?veaction=edit with "Visual Editor" unchecked can lead to the visual editor.

And something additional:

(Bug) Non-latin characters in the editor can cause many problems, just like unproper wrap in visual (In a word, when I selected some characters in line X, and 'Delete'. Words in line X+1/X-1 has been deleted.) and failure to insert characters at the head of the line.

(Feature) When I use proxy to edit and view some wikimedia project (Banned by goverment), it has a slow connection speed and low-raliablity transfers. Yes... You can guess what I wanna to know is the cache of the wikitext editor data/js/css file. Can these files are preloaded with other JS file or can be cached for freqently use.

Sorry for poor English, Thanks :D

Use ...?action=submit to get an older wikitext editor.

Can you tell me which web browser and what kind of computer you're using? For example, many editors use Chrome on Windows 10, and I'm currently using Safari Version 12.0.3 (13606.4.5.3.1) on macOS High Sierra 10.13.6 (17G5019).

Also, if you know what "IME" or keyboard systems you're using, that might be helpful, too.

Thanks for reply.

When I got into the bug I'm using Chrome 71+, Windows 10 (1809) and MS Pinyin IME (Windows original). But recurring this issue again is hard for me now because I am using Linux... With Linux + Chrome/Firefox, it's fine.

yes in the hamburger (☰) menu

default wikitext editor has syntax hilighting optionnaly enabled, it is possible to do with new wikitext editor ?

Yes. Look in the "hamburger" (☰) menu, towards the end of the list.

thanks