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

I'm used to edit in a second and this editor is slower and adds summary screen to the flow. Over 7 seconds for a simple edit.

Tracked in Phabricator
Task T223191

The edit summary preview doesn't work. It just shows the placeholder $1.

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.

I have found it worthwhile to learn the Keyboard shortcuts for this command. They are the same ones that you use in the older wikitext editors.

Maybe I am blind but I can't find a shortcut for preview in the overview you linked above :(

Can you write it here?

Oh, my fault! You need the main list at m:Help:Keyboard shortcuts, not the extra handful added to VisualEditor.

On my Mac, it's Control+⌥ Option+p and Ctrl+⌥ Option+v for preview and diff. The meta keys are different in Windows (and sometimes by web browser).

It is very hard to rewrite text, and it loads slow like Visual Editor.

I'm sorry that it's slow to load.

Can you tell me more about problems with re-writing text?

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?

CharInsert (sometimes called "Edit tools") is not supported. I don't think that the team is planning to support it. Which codes do you need it for?

Latin accented vowels. Always useful to have that around and would be sad to see it go.

A special characters tool built in to the visual editor's toolbar. Look for an icon that looks like Ω next to the Insert menu.

Below are some remarks I post on behalf of a friend who asked me for help because he prefers not to post his comments in English. He uses the latest Firefox on Windows 10.

• First, he suggests the edit summary in wikitext 2017 editor should provide an interface that can be easily filled in with the usual tool provided by Firefox. As it is now, summary text has to be put in anew with every edit you make, even it you have put it in earlier. There should be a way to make it easier for you to complete summary texts you had used before.
• Then, there should be a flag in your settings to make it mandatory to put in a summary text in the publishing dialogue if a user prefers to. The flag there is for the traditional wikitext editor seems not to work with the wikitext 2017 editor.
• Also, there is no button in the publish dialogue to abort publishing. You can abort by pressing the ESC key, but there is no message which tells you so.
• Lastly, he misses the table of contents and the sidebar in preview for checking if all images, tables, etc. are in place before saving. He would prefer to have a complete page preview available before publishing his edit.

Perhaps some of these feature requests are already being discussed or even worked on. – Thanks in advance.

Since there were no replies to the remarks I had handed on I just would like to remind you that we are still listening and we would like to know whether someone will address the requests? TIA.

Sorry about the delay in replying. Here are some of your answers:

• The edit summary question was addressed last week in phab:T50274. I am curious whether you all think it is an improvement.
• The preference setting for warning (once) about adding an edit summary exists, and works.
• There are multiple methods for aborting an edit. In 2013, there was a Cancel button, but as I was almost the only person who used it regularly, the team decided to remove it and use that "real estate" for something more valuable.
• The Table of Contents is on the list, but I don't know how long it will take for it to happen (it's been more than a year since it was originally requested, so... probably not soon.  :-( )

Being able to see the sidebar with the Preview has been requested by several editors (it's part ofphab:T155732), and I don't really "get it". Why does this matter? As far as I understand, the answer is "so it will look exactly like what the page is when it's saved"... but that only shows you what it looks like for a person with the exact size and shape of window you have, the exact font and font size you use, the same zoom level you use – in other words, for almost nobody else who's going to read the page. Is there a practical value in being able to see the sidebar during Preview, or is this request about keeping a familiar appearance?

@Whatamidoing (WMF): Thank you for your reply. I am pleased to see that some of the features we mentioned have been implemented in the meanwhile, and I think that's a good thing I would like to thank you for.

We have discussed these points again, and as far as the TOC and the rest of the weblayout and the interface in VE is concerned, I think what we see here reminds me of a decision taken recently by the developers of Firefox. They removed the RSS reader and the live bookmarks from core because hardly anyone used it anymore. You have to install add-ons if you still want to use these features now. Turning to Wikipedia we've just had the case of the old Wikitext editor switched off for more or less the same reason. In both cases, however, it turned out that a small group of power users that more or less keep the project running still relied on those tools, and because the decisions were taken on the basis of metrics for a much broader set of users the needs of this rather important core community were not taken into account as they should have been.

I think the same holds true for the features discussed here because a very active user should find all the elements he is used to in the new interface. I for one often switch between VE and Wikitext because each interface provides me with features I miss in the other. (I also had to switch to the standard Wikitext editor completely because Wikitext 2017 too often fails to load so that I could not edit altogether, but that's different story.)

This means that, as in the standard Wikitext editor, there should be a cancel button in VE, there should be a TOC and a sidebar when an interface provides WYSIWYG (because this is what you will get in the end) and so on, even if what you get depends on the system the reader of the text uses which means that this will very probably differ from what the author sees on his screen at time of writing. When we talk about the editor, only the interests of the author come into play, reading is something quite different.

So, after all, you might like to re-consider your entire approach about how to assess and how to decide about what is needed and what is not, taking into account the needs of the core community which may only some 200 or 300 users or even less that are most active and that have been editing Wikipedia for many, many years. Old habits are hard to break, and they should not be broken.

The WMF is no longer supporting the 2006 wikitext editor; instead, volunteers are taking care of it.

I know the German Wikipedia didn't bother to install the gadget until after it was removed from the server – I saw an editor begging the int-admins there to take action for at least two weeks – but it's there now: Go to Prefs, click on the Gadgets tab, and click "Bringt die Bearbeitungsknöpfe des Quelltexteditors zurück (der sogenannte 2006-Editor)". I firmly believe that active contributors who have been editing Wikipedia for many, many years can turn on a gadget. OTOH, if they're similar to the English Wikipedians who used that editing environment, most of them didn't really want any toolbar at all, so there might be fewer people using it now.

> When we talk about the editor, only the interests of the author come into play, reading is something quite different.

I don't think this is entirely true. When you are editing, you probably want the editing system to result in something that works for:

• you
• RecentChanges patrollers and others who review your edits, and
• the people who read what you write.

You-the-editor wouldn't really be well-served by a tool that produces something that looks nice to you, but frustrates readers or RecentChanges patrollers.

After a discussion: We beg to differ here. When editing an article we need an interface that gives you a proper impression of what the article will look like after saving your edit. The TOC is part of this. This holds true especially when editing long articles with a complex structure. There should be better support for editing and navigating in long articles. I mean articles that have some 20, 40, or 60 pages or even more when you print them on paper. I wonder whether developers are aware that this is what experienced authors do when editing Wikipedia? We would expect to find a TOC in the rendered article text when previewing. Another option could be a navigator as you can find in text processors, e.g., as a drop down menu in the editor window, to be able to jump to a given mark in the text and to have an overview ot its overall structure.

As far as the old Wikitext editor is concerned, as I already said, I do not mind. I am sorry about the new Wikitext editor aborting to load since the beginning of the year. That's why I switched back to the standard editor for plain text.

workaround: use action=submit to use the old editor

User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

When I try to open a preview window, it loads forever without showing anything, and a “TypeError: titleAndFragment is null” appears in the web console.

I know this editor doesn’t officially support translatable pages, but what am I supposed to do? Disable the beta feature every time I want to edit one? I can’t find a way to load the old wikitext editor when necessary.

URL: https://www.wikidata.org/wiki/Help:Property_constraints_portal/One_of?action=edit

I'm sorry that you've encountered this serious limitation so often. I leave the 2017 wikitext mode disabled at Meta for exactly that reason.

As a workaround, you can hand-edit the URL to say action=submit (instead of action=edit or veaction=editsource). The "submit" action isn't valid for the 2017WTE, so it will switch you to an older wikitext editor. I have generally found that's faster and less annoying (for me) than constantly changing the prefs.

Thanks, action=submit is enough to solve my problem for now. Let’s just hope I remember it next time I run into this :)

Tracked in Phabricator
Task T221684

Previews don't render hotlinked images and images using HTML img tags. This has caused confusion on wikis with $wgAllowImageTag and $wgEnableImageWhitelist set to true. See https://phabricator.miraheze.org/T4316#82239.

Thank you for bringing this issue to Wikimedia's Phabricator, Whatamidoing.

• Writing no-break spaces in the new editor doesn’t work. I get usual spaces when I type a no-break space. No-break spaces do work in other MediaWiki editors, including the previous wikitext editor and the translation tool which is used on MediaWiki.org and Meta. No-break spaces can be typed with some keyboard layouts including mine (Bépo, which is a Dvorak-like for French; also the fr-oss layout with AltGr-Shift-Space). We can still use the HTML entity   but in my case it’s harder to write, and it makes the code uglier.
• On some pages on fr.wikiversity (example of such a page), the cursor is not at the right place, it is shifted. To make editing comfortable, I have to open the browser inspector and edit manually the .ve-init-mw-desktopArticleTarget .ve-ui-mwWikitextSurface .ve-ce-attachedRootNode rule so that it has the same padding as the .ve-init-mw-desktopArticleTarget .CodeMirror rule.

Thank you for reading and dealing with it.

• This request is documented at phab:T53045.
• Are you using a monospace font for editing? Using a variable-width font (like Times or Arial) causes problems with the CodeMirror syntax highlighting tool.

• No it’s not. This request talks about creating a shortcut to insert no-break spaces. I’m talking about allowing to write no-break spaces when your keyboard layout already allows you to write no-break spaces. What I’m talking about is something that works with the most stupid text editor you can have. What is asked for on phab:T53045 is an advanced feature you usually have on a word processor which is usually quite an important piece of software. To my mind you shouldn’t deal with phab:T53045 but you should deal with my request. No-break space is a special character among many others; if you want to type one you should either have it on your keyboard layout (like me) or find it in a character table. However, whereas many important keyboard layout don’t offer the no-break space, it might still be important to type no-break spaces in formatted texts, but for the French case, MediaWiki already puts no-break spaces in the most important places (notably before colons and semicolons). But currently it’s simply not possible to type a no-break space even if you have it on your keyboard layout, and it’s pretty weird. It is not a feature request but actually a bug.
• Yes, I am using a monospace font. Sorry, my link was wrong, it should have leaded to fr.wikiversity (I’ve just fixed it). There’s a rule: .ve-init-mw-desktopArticleTarget .ve-ui-mwWikitextSurface .ve-ce-attachedRootNode { padding: 0 1.8em; } for the colored text. And e.g. here there’s a rule .skin-vector .ve-init-mw-desktopArticleTarget .CodeMirror { padding: 0 1.8em; } for the code editor, so things are OK. But here, the latter rule is not present, so it fallbacks to .ve-init-mw-desktopArticleTarget .CodeMirror { padding: 1.5em; }, which is different from the first rule and makes the text field shifted from the text display. I believe there’s a stylesheet structure problem. It might be quite specific to fr.wikiversity, but well, then you should probably inform the wikis or check for this yourself.

I also have another bug.

• Copy-pasting with middle click (on Linux) don’t work in the new editor (nor in the visual editor). I use this feature extensively… Currently on Firefox it pops a navigation tool (that thing which allows you to scroll the page by placing your mouse on the right side of it), and after the first click it does a copy-pasting but without moving the cursor, while usually this moves the cursor to the location on which you click. There’s much chance it’s already documented on Phabricator.

The inability to copy–paste with middle click on Linux looks like another CodeMirror problem: phab:T174635.

When they add the ability to insert a non-breaking space, they'll obviously have to start accepting them. That said, so long as enwiki tells people not to use 'invisible' non-breaking spaces, and therefore WikEd (a volunteer-supported editing environment preferred by some power users) keeps replacing them with the HTML code for non-breaking spaces, I wouldn't be surprised if the result was VisualEditor substituting the HTML code for non-breaking spaces rather than just leaving the actual non-breaking space in the wikitext (which is what I would personally prefer).

Adding no-break spaces through a special feature and through the ‘generic’ way (that works everywhere else on the system) is actually a different thing. You might be right, but I don’t think so; in any case, it’s not ‘obvious’. The editor is probably already able to edit pages that already contain no-break spaces, otherwise it would break things. If you add a way to add no-break spaces, it won’t certainly fix my bug.

Indeed   works in the wikitext editor, therefore I agree it’s not really an important feature to be able to insert no-break spaces with the wikitext editor. I didn’t even noticed that the Phabricator task you linked was about the VisualEditor… But   might be a too ugly syntax. Sometimes you might prefer to write no-break spaces directly in the code because it makes it more readable, and people should now that they have to write a no-break space at this place.

I’ll involve in the Phabricator task.

Thank you for your answer about the copy-pasting bug; indeed I’d already encountered it with CodeMirror.

VisualEditor is both "the visual editor" and "the new wikitext mode" (aka 2017 wikitext editor).

OK. Thanks.

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.

I can't reproduce on this wiki. Are you still having this problem? (Make sure that you have enabled the new wikitext mode in Special:Preferences#mw-prefsection-betafeatures and try editing Category:VisualEditor. You can revert any changes that you save.)

It seems it works now in both browsers. Thanks, Whatamidoing (WMF).