2017 wikitext editor/Feedback

Jump to navigation Jump to search

About this board

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 PhabricatorJoin the IRC channel

Feature: VisualEditor's text editing mode intentionally does not encourage null edits

Brainulator9 (talkcontribs)

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

Jdforrester (WMF) (talkcontribs)

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

Brainulator9 (talkcontribs)
IKhitron (talkcontribs)

We use'em all the time.

Jdforrester (WMF) (talkcontribs)

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

Alsee (talkcontribs)

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

Brainulator9 (talkcontribs)

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

IKhitron (talkcontribs)

You are kidding?

Alsee (talkcontribs)

@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.

IKhitron (talkcontribs)

Absolutely. I'm talking about null edits.

Reply to "Feature: VisualEditor's text editing mode intentionally does not encourage null edits"
Newslinger (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

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

Newslinger (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)
ESanders (WMF) (talkcontribs)

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.

Newslinger (talkcontribs)

Okay, I understand. Thanks for your consideration.

Reply to "Option to turn off animations"
Sjschen (talkcontribs)

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?

Reply to "Special characters menu"

Feature:Switch back to old editor

Summary by Whatamidoing (WMF)
Erentar2002 (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

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?

Erentar2002 (talkcontribs)

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)

Whatamidoing (WMF) (talkcontribs)

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.

ESanders (WMF) (talkcontribs)

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.

Reply to "Feature:Switch back to old editor"

Bug when editing category pages

Paucabot (talkcontribs)

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.

Reply to "Bug when editing category pages"
Lesendes Okapi (talkcontribs)

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 :) --~~~~

Erentar2002 (talkcontribs)

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

Paucabot (talkcontribs)

I agree.

Reply to "Preview button"

Need a short personally customizable quick-launch toolbar

Timeshifter (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)
Timeshifter (talkcontribs)

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


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).

Whatamidoing (WMF) (talkcontribs)

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.)

Timeshifter (talkcontribs)

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.
Whatamidoing (WMF) (talkcontribs)
Timeshifter (talkcontribs)

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.

Reply to "Need a short personally customizable quick-launch toolbar"
HaiZebrazach20062 (talkcontribs)

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)

Alsee (talkcontribs)

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.

Reply to "Text editing issue"

How can I use the traditional wikitext editor while the beta version is turned on?+ More things

Summary by Whatamidoing (WMF)
小老虎3018 (talkcontribs)

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

Whatamidoing (WMF) (talkcontribs)

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

Whatamidoing (WMF) (talkcontribs)

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. 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.

小老虎3018 (talkcontribs)

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.

Reply to "How can I use the traditional wikitext editor while the beta version is turned on?+ More things"

is there a syntax hilighting ?

Summary by Xavier Combelle

yes in the hamburger (☰) menu

Xavier Combelle (talkcontribs)

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

Whatamidoing (WMF) (talkcontribs)

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

Xavier Combelle (talkcontribs)