2017 wikitext editor/Feedback/2018

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

Can't be disable

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This Feature can not be disable. I Uncheck this and the save but still is enable, I using on Persian Wikipedia. NameGame (talk) 13:34, 17 January 2018 (UTC)

I'm sorry that it's not working correctly for you. Please see 2017 wikitext editor/Feedback/2017/05#h-Cannot_disable_the_editor-2017-05-13T03:57:00.000Z. Whatamidoing (WMF) (talk) 22:33, 17 January 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Syntax highlighting gets confused by extra lbrace

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Someone accidentally replied to me using {{{Ping|…}} instead of {{Ping|…}}, and as a result in the 2017 wikitext editor all following Wikitext is colored in orange (class cm-mw-templatevariable). In the rendered article, the extra { is simply emitted into the text without influencing the following Wikitext, so the syntax highlighting is misleading. Lucas Werkmeister (WMDE) (talk) 15:43, 19 January 2018 (UTC)

I would recommend filing a new task against the syntax highlighting feature. While we have integrated it with our editor, we are not the team maintaining the wikitext rules for the highlighter, so hopefully it will get the right attention on phabricator.

Thanks, ESanders (WMF) (talk) 23:05, 12 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Not being able to explore the source word

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When I open the tool "explore the source word" and this tool at the same time,I find it confusing that the page jumps to an Editing page.I wonder if it is a bug. チルノ (talk) 15:52, 19 January 2018 (UTC)

Thank you for your message. Could you please give me a link to the page that you were at, and tell me what you were clicking on? Whatamidoing (WMF) (talk) 00:00, 28 January 2018 (UTC)

Well,I am a zh Wikipedia user.The reference setting of it is called"参数设置" in Chinese.And in the "小工具"(small tools) button,under the title "界面显示工具"(Displaying tools),there is a option called"編輯頁籤及編輯段落連結（[編輯]）附帶檢視原始碼（[源碼]）連結 點按[源碼]會帶到唯讀模式下查看源碼，編輯框文字會被鎖定而不可改動",which shows an button after the article's title to a page showing the source words.After I switch it on and this new tool at the same time ,I find the link "源码"is redirected to this new editor.In other words,I can't only see the source word.Sorry for my poor English. チルノ (talk) 04:07, 28 January 2018 (UTC)

Here's what I did:

1. Go to https://zh.wikipedia.org/wiki/Special:参数设置#mw-prefsection-gadgets
2. Enable item #8 in the fourth section of that page.
3. The new tool gives you a link (if your interface language is set to Chinese) that says, e.g., https://zh.wikipedia.org/w/index.php?title=数学&action=edit&section=0&summary=/*%20首段%20*/%20&viewsource=1
4. But if you have the new 2017 wikitext editor enabled, then "&viewsource=1" is ignored. The page opens and you can edit it normally.

This means that they are not supporting "viewsource" yet. I will file a bug report for the developers. Thank you for explaining this to me. I really do appreciate it. Whatamidoing (WMF) (talk) 17:36, 29 January 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Strange character sequence conversions

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Steps to reproduce

1. Open m:User:Kaartic/sandbox
2. Edit as source using the '2017 wikitext editor'
3. Type t= and ]]

Expected results

I see t= and ]] entered in the editor.

Actual results

• t= gets converted to θ
• ]] gets converted to ʼ

Note

This has unintended consequences when trying to manually edit the [[File:...|...]] syntax. Kaartic ^[talk] 11:44, 29 January 2018 (UTC)

Sounds like you've got an IME or odd user script interacting with input? https://meta.wikimedia.org/w/index.php?title=User:Kaartic/sandbox&diff=17687101&oldid=17686088 worked fine for me… Jdforrester (WMF) (talk) 17:05, 29 January 2018 (UTC)

Seems you're right. Unknowingly the IME switched to "International Phoentic Alphabet - SIL" from the usual"Native keyboard" which seemed to have caused this odd behaviour. Not sure how it got changed but it's fixed now. Thanks! Kaartic ^[talk] 10:47, 30 January 2018 (UTC)

Kaartic, does it happen to you at other wikis, or if you're logged out/in a private browser window? Whatamidoing (WMF) (talk) 17:50, 29 January 2018 (UTC)

I suspect this happens whenever the IME is "International Phoentic Alphabet - SIL" which I didn't realise previously. Kaartic ^[talk] 10:48, 30 January 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

UI feedback: "Review Changes" shouldn't only be behind "Publish" button.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When I make an edit, I almost always hit the review changes button to make sure I haven't accidentally changed anything I didn't mean to (e.g. by accidentally typing a random keyboard letter in the middle of the document while scrolling past it) . The visual wikitext editor puts this feature, and the Preview button, in a separate dialog that only appears after hitting Publish.

For me, this is a very unintuitive UI flow. I don't want to "publish" my edit until after verifying that it's correct and safe. When I'm done changing whatever I want to change, my first instinct is to look around for the diff and preview buttons, and to avoid going anywhere near "Publish" until I've double-checked my work. If a change is only half-done and I want to look at the preview to to see if I used a template correctly, it feels dangerous and uncomfortable to click "publish" with the editor full of not-ready-to-publish work.

The old wikitext editor has separate preview and changes buttons next to the publish button, instead of requiring the user to click the publish button first. Please add similar buttons next to the publish button in the visual editor, or at least a drop-down menu containing them. NotTheInferno (talk) 22:14, 7 February 2018 (UTC)

Tracked in Phabricator
Task T153306

There have been a long stream of complaints about this over a year. So far no one at the WMF has indicated they are going to do anything about it.

I see you came here from English Wikipedia. There's an EnWiki community consensus to block the 2017Editor from being rolled out as the new default editor for more fundamental reasons. So the community has been quite disinterested in having anything fixed. Alsee (talk) 23:13, 7 February 2018 (UTC)

So far no one at the WMF has indicated they are going to do anything about it.

This is not true: https://phabricator.wikimedia.org/T153306#2976930 https://phabricator.wikimedia.org/T153306#3044327 https://phabricator.wikimedia.org/T44138#3579353

Please do not say that people saying "we will fix this" is failure to indicate that things are going to be done, instead of on-going design discussion about best ways to do this. Jdforrester (WMF) (talk) 00:31, 8 February 2018 (UTC)

I second this. I just came here for this very issue, after accidentally publishing an edit without an edit summary, because I thought that "Publish edit" would take me to a box where I could input an edit summary, which it didn't, because I was in article preview. It's really confusing that one button has two different functions depending on your current mode. Pinnerup (talk) 11:03, 9 February 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Cannot "source edit" the image descriptions

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

They are first displayed, then converted into something read-only. Wakeup12 (talk) 10:27, 8 February 2018 (UTC)

@Wakeup12, please see How_to_report_a_bug/tr to see how to provide more information. I can't reproduce this issue, and I have tried to both edit an article and the File: page for the book cover that it included, edited by you at tr.wikipedia. Elitre (WMF) (talk) 13:48, 8 February 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Unterschrift Button im Neuen Text Modus

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Im neuem Text Modus fehlt der Button zum unterschreiben.

Das sollte noch nach gebessert werden. Diamant001 (talk) 15:00, 11 February 2018 (UTC)

Hi, it actually isn't. See https://commons.wikimedia.org/wiki/File:VisualEditor_Insert_Menu-de.png (I believe "Mehr" is what you click on to expand that menu). It is disabled and can't be used on namespaces where such a button should not be used like the main namespace, but available in others where it could be necessary, like the Wikipedia one. Elitre (WMF) (talk) 10:25, 12 February 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Return to normal after previewing changes

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This is currently confusing MonoBook styles. After reloading to get the standard styles back in for MonoBook you end up in editing mode.

Fx 58, Linux Mint 18.3 [[kgh]] (talk) 19:50, 11 February 2018 (UTC)

Using steps to describe the issue would help a lot. See How_to_report_a_bug#Quick_recommendations? TY! Elitre (WMF) (talk) 10:20, 12 February 2018 (UTC)

1. https://www.mediawiki.org/wiki/Project:Sandbox?veaction=editsource
2. Add or remove something
3. Click "Publish changes"
4. Click "Show preview"
5. Click "Resume editing" or "Publish changes"
6. Bang. [[kgh]] (talk) 12:33, 12 February 2018 (UTC)

Thanks.

That already helps us understand you're talking about this wiki, which isn't necessarily something to take for granted.

By following precisely your steps, although with a different setup, I do see a problem with Monobook. I should probably point out that "Resume editing" is supposed to take you again in editing mode, while "Publish changes" for me just published regularly.

Also, "reloading to get the standard styles back in for MonoBook" isn't a step in your latter comment. If I do that after step 5, I get a normal page in Monobook - but again, it is possible that FF is at fault there.

I have already heard reports about weirdness in FF today that was fixed by upgrading to the very latest version: please let us know whether upgrading to last week's version changed anything.

(Also, not going to reproduce step 6 :p ) Elitre (WMF) (talk) 13:56, 12 February 2018 (UTC)

I guess it does not really matter if we are talking about this wiki or not since MonoBook is a standard skin. However it helps understanding and replicating the issue in an easier way.

Ah I did not think of my last comment. I was not able to replicate this today. So one issue less.

The other steps however were done with Fx 58.0.2

Yeah, Bang is an interesting one. :D [[kgh]] (talk) 14:25, 12 February 2018 (UTC)

It certainly matters. I don't get the same issue on en.wp, for example. Each wiki has its configuration, and for all we know right now that could be the actual problem (maybe it won't, but we def shouldn't exclude it a priori). I am not sure what you were unable to replicate today. However, I filed https://phabricator.wikimedia.org/T187075 as a start. Elitre (WMF) (talk) 15:22, 12 February 2018 (UTC)

Thanks a lot! This does no longer happen to me: After reloading to get the standard styles back in for MonoBook you end up in editing mode. [[kgh]] (talk) 15:30, 12 February 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Errors copying source code from one article to another

As far as I understand, it's kind of a feature, rather than bug, but it's very inconvenient.

When copying, nowiki tags get added to each line, double line breaks are removed and div block is added at the end. Those are visible changes, though and they could be undone manually.

However, there're invisible changes as well and some may brake template functionality. Please look at history of this page I had to fix to make templates work: https://ru.wikipedia.org/w/index.php?title=%D0%9A%D0%B0%D0%BD%D1%82%D0%BE%D0%BD_%28%D0%A2%D0%B5%D1%85%D0%B0%D1%81%29&type=revision&diff=90952690&oldid=90950606

Multiple spaces are throttled with something invisible..

Thanks! Flomru (talk) 19:38, 15 February 2018 (UTC)

I understand that CTRL-SHIFT-V for pasting allows you to avoid the former issue.

I am not entirely sure if that template has TemplateData. Help:TemplateData has information that will allow you to specify if the template should be shown as inline, block, or in another custom format. After that happens, the preference will be respected. Elitre (WMF) (talk) 11:41, 16 February 2018 (UTC)

Oh, I should've realized there's a plain text paste option. Sorry about bothering you.

Plain text paste works as before, there's a minor issue I've seen before but not reported (maybe it is repoerted by someone else):

When I paste (for example, source code of the page above, :ru:Матадор (Техас) ) to a new page, it stops showing text after 6th line ("изображение" field), showing remaining as a blank space instead. It is easy to fix just by deleting line break after that line and entering it back, but I thought it might help to improve editor

Thanks! Flomru (talk) 14:32, 16 February 2018 (UTC)

Looks good to me? Can you still reproduce that reliably, from example from another browser, or while logged out? Elitre (WMF) (talk) 14:00, 22 February 2018 (UTC)

Now that I've experimented with it a little, I think it's rather syntax highlight extension Extension:CodeMirror issue. Or the conjunction of two.

Here's what I get when I copy text from

https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BB%D0%BE%D1%80%D0%B0%D0%B4%D0%BE-%D0%A1%D0%B8%D1%82%D0%B8_(%D0%A2%D0%B5%D1%85%D0%B0%D1%81)?veaction=editsource&safemode=1

to

https://ru.wikipedia.org/w/index.php?title=%D0%A1%D1%83%D0%B8%D1%82%D1%83%D0%BE%D1%82%D0%B5%D1%80_(%D0%A2%D0%B5%D1%85%D0%B0%D1%81)&action=edit&redlink=1&safemode=1

In chrome: https://imgur.com/An6fXrH

In IE: https://imgur.com/pjFK8NF

I'll start a thread on extension talk page.. Flomru (talk) 14:41, 22 February 2018 (UTC)

Probably https://phabricator.wikimedia.org/T185184, and if so this thread could be closed. Elitre (WMF) (talk) 11:23, 28 February 2018 (UTC)

Please make clear to the user that Ctrl+Shift+V is a thing. After pasting, a little info box could appear. I had to come to this page here to learn about it. ToBeFree (talk) 19:07, 18 March 2018 (UTC)

Cannot access deletion log for nonexistent pages

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

In the classic wikitext editor, when you create a page that was previously deleted, there is a notice listing previous deletions (and moves). This is convenient because it gives an indication of previous problems with the page. With this new editor, I can't find it anywhere. I won't object if it's less prominent, but I would like to be able to access it somewhere. Anon126 (talk) 22:54, 18 February 2018 (UTC)

There's https://phabricator.wikimedia.org/T176070 and related tasks for that, I think. Thanks. Elitre (WMF) (talk) 13:56, 22 February 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

First impressions

I finally decided to try out the new wikitext editor, but after only a handful of edits I've reverted to the original one. There are two fundamental issues that, for me, are show-stoppers:

1. It takes significantly longer to load than the traditional wikitext editor.
2. entering an edit summary requires loading a separate dialog box (rather than just being below the editing box) and thus cannot be tabbed to.

The edit summary box not storring previous edit summaries and pressing enter not saving the edit are also issues but not critical ones.

In namespaces where the visual editor is available there are only three reasons I use the source editor these days. The first is to do things that are either not possible or much more complicated in VE (most commonly this related to adding columns generated by the {{convert}} template to tables) or for very simple edits (fixing single typos, and the like) and for making the same edit to multiple pages in quick succession using copy and paste.

The new source editor seems to have no advantages or disadvantages over the old editor for the first type of edit. For the second type of edit the time taken from clicking edit to saving the edit is the most important and the combination of the issues listed at the start of this post mean the old editor wins by a country mile. For the third type of edit, the second issue noted above means that the workflow changes from:

1. move cursor to correct point of text (mouse)
2. paste (keyboard)
3. tab (keyboard)
4. add edit summary (keyboard)
5. save (keyboard)

to:

1. move cursor to correct point of text (mouse)
2. paste (keyboard)
3. open save dialog (mouse)
4. enter edit summary (keyboard)
5. save (mouse)

increasing the complexity and time taken for each edit.

I expect that resolving these issues would mean some fundamental changes to core design choices, so this is submitted as general feedback not as a bug.

If it were possible to choose which source editor to use on a per-edit basis then I can see how some of the tools might be useful on occasion in namespaces where VE is not available, but at present it's a very poor match for the way I work. Thryduulf (talk) 12:47, 21 February 2018 (UTC)

The fact that web browsers won't store the edit summaries in that kind of dialog is one of my long-term annoyances.

In Step #3, you can use the VisualEditor/Keyboard shortcuts to skip the mouse steps for saving. But you're still going to have to re-type the edit summary, so it will still take a little longer even with the keyboard shortcuts. Whatamidoing (WMF) (talk) 01:51, 26 February 2018 (UTC)

Previewing edits is needlessly inconvenient

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Under the old system, it was quite straightforward to see what you were doing. There was a preview of the page at the top and a code editor beneath, so you could see both at the same time. This made it easy to understand the wikitext at a glance. With the 2017 editor, you can only look at one at a time, and the preview button is rather unintuitively hidden under the publish button. Could I suggest that you revert in some way back to the old approach? The article preview could perhaps be put in a scrollable box above the editable region. GKFX (talk) 10:45, 1 March 2018 (UTC)

Tracked in Phabricator
Task T153306

This is a commonly reported issue. There has been a Phabricator task open for it since 2016. You can view it at the attached link. Alsee (talk) 04:17, 2 March 2018 (UTC)

Okay, thanks! GKFX (talk) 09:50, 2 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Typing and copying

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I've got a bit of an issue with the 2017 wikitext editor. It's entirely possible for me to type too fast and cause the text to come out of sync with the contents - causing multiple lines of greyed text or having the text not reflect what I've typed. A recent example: https://en.wikipedia.org/w/index.php?title=List_of_Apollo_missions&diff=828614753&oldid=828614216 - I started typing Access, decided to do publisher first, and it got mangled. I type 72 (or so) words a minute and I am using Firefox Quantum latest version. ~ Matthewrbowker ^{Talk to me} 18:37, 3 March 2018 (UTC)

Forgot some info - I am using MacOS 10.13 on Timeless. Though I've also seen this issue in Monobook. ~ Matthewrbowker ^{Talk to me} 18:39, 3 March 2018 (UTC)

Are you using syntax highlighting as well? We've made some recent improvements to text processing, so maybe check back in a few weeks when that is deployed. ESanders (WMF) (talk) 19:28, 3 March 2018 (UTC)

Ed, I thought all our recent work in the area was deployed weeks ago? See another report from Gryllida. Elitre (WMF) (talk) 19:00, 8 March 2018 (UTC)

Yes, I'm using syntax highlighting. And I will re-enable in a few weeks, thank you. ~ Matthewrbowker ^{Talk to me} 20:57, 3 March 2018 (UTC)

Hi again. How is it going these days? Elitre (WMF) (talk) 15:17, 21 March 2018 (UTC)

Just enabled it again, will give you an update when I get to editing this evening US. ~ Matthewrbowker ^{Talk to me} 16:59, 21 March 2018 (UTC)

A number of weird bugs has been observed and fixed lately. Not sure the fixes are all live. Will revisit next week to see if all's good or not. Thanks for your patience! Elitre (WMF) (talk) 16:43, 16 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Cannot see the full ramifications of the edit before publishing

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hello.

While I love the new 2017 wikitext editor because of its expanse, it is impossible to see the full ramifications of the edit before publishing it. This was not the problem with the old wikitext editor. More specifically:

• Accidental misspelling of a category's name is not seen in the preview.
• List of used templates won't get updated.
• The effect of {{lowercase title}} or other title-changing code cannot be previewed.
• Category changes resulting from addition of new templates do not appear in the preview. For example, try inserting a {{Use British English}} template in English Wikipedia. Codename Lisa (talk) 10:32, 4 March 2018 (UTC)

In January-March 2017 there was an RFC at English Wikipedia to block deployment of the 2017Editor due to preview errors and poor performance. The issue is tracked at Phabricator task T154844. However there has been no progress, and the manager of the project appears intensely opposed to a real fix. The task is rated "LOW priority", which generally indicates little prospects for action in the foreseeable future.

I'll add your cited concerns to the Phabricator discussion. Alsee (talk) 19:39, 4 March 2018 (UTC)

Hello, Codename Lisa!

The blue-linked cats are a regression. I've re-opened the bug. Whatamidoing (WMF) (talk) 00:02, 8 March 2018 (UTC)

Update: It appears that it's a bug that produces the same symptom, but not technically a regression. A fix seems to be on the way, thanks to the ever-awesome User:DLynch. Whatamidoing (WMF) (talk) 19:06, 9 March 2018 (UTC)

Please send my best to the awesome User:DLynch. Right now, I have a wallpaper of a cat with a blue link. It took me a while to understand what "blue-linked cat" means. Codename Lisa (talk) 19:11, 9 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Wrong line

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This tool constantly edits the wrong line. I try to type content on line 1, it starts displaying my characters on line 3. Is this not a known bug that is faced by every human being who tries to use this product...? I experience it in both Firefox and Chromium. Gryllida 04:36, 8 March 2018 (UTC)

Please notice that that task is closed. I am unaware of regressions.

You could file a new task describing the issue in greater detail. Maybe first you can troubleshoot to see if the issue depends on your configuration. Elitre (WMF) (talk) 18:55, 8 March 2018 (UTC)

I see a report below that could be related. Elitre (WMF) (talk) 18:59, 8 March 2018 (UTC)

Gryllida, I'm sorry that you're dealing with this. It would drive me nuts. Do you, by any chance, also have the syntax highlighter enabled? Whatamidoing (WMF) (talk) 19:04, 9 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Strange text replacement issues in Wikiversity

In Wikiversity, typing most symbols eg { [ ~ = causes previous characters to be modified and alternative symbols to be added. I've only observed this error in Wikiversity since last week. Other wikis work fine. Example copied from my sandbox:

Typed "{{{{~~[[[[::"

Displayed ˌˈˌˈ ̃~ ˞ʽ˞[ʼːˑ

Any ideas? T.Shafee(Evo﹠Evo)^talk 23:10, 22 March 2018 (UTC)

Yes: See if you've accidentally enabled the IPA keyboard. You'll find this in the lower left corner of the editing window. It looks like a little black keyboard. Click it and make sure that it says "Use native keyboard" and not "International Phonetic Alphabet" (or anything else that you don't understand). I think this can also be found in the sidebar, halfway down, in the gear by "Languages". It's an "input" setting. Whatamidoing (WMF) (talk) 19:17, 23 March 2018 (UTC)

Ha, thanks. An obvious answer now that you point it out! Perhaps there could be a little notification bar appear at the top when in IPA keyboard mode for people (like me) who accidentally get stuck in it. T.Shafee(Evo﹠Evo)^talk 00:40, 24 March 2018 (UTC)

Given how confused I was the first time that happened to me, I think that "a little notification bar" is a bit too subtle. Maybe something large and red and blinking? ;-)

Making the change a bit more obvious is a good idea. Maybe a fade-away notice, similar to the "Your edit was saved" announcement? Or perhaps a smaller, more persistent banner? There are probably several good ways to address it. @Amire80, does your team own this? Whatamidoing (WMF) (talk) 17:47, 26 March 2018 (UTC)

Drag and drop a suggestion in the Wikidata searchbox and a bug

This has issues, see https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Copy_pasting_an_item_from_the_searchbox

Unrelated : I also noted that the first suggestion in Wikidata is masked by the blue post button on wikitext edition mode. TomT0m (talk) 10:15, 27 March 2018 (UTC)

Hi, sorry for the late reply. I have read your example but I don't think I grasped the problem.

I would appreciate if you could describe more accurately the steps to reproduce, and in particular what you expect and what happens instead. Thanks. Elitre (WMF) (talk) 15:13, 11 April 2018 (UTC)

@Birgit Müller (WMDE), is that second item in your territory? Whatamidoing (WMF) (talk) 18:03, 13 April 2018 (UTC)

Confusing layout

I find confusing that the Cancel button everywhere is just text in red color and not a button, it looks like a red link. I also find strange that if I want to "Preview changes" I have to press on "Publish changes" first, it should be called "Manage changes" or something like that instead. Then there is the dialogue called "Save your changes", which has a very random organization... I don't know what was the rationale for such arrangement but for me it doesn't make sense to have 4 buttons, when you could have only 3 and a cross to close the dialogue. The title "Save your changes" is also superfluous when the button says specifically "Publish changes". And there should be also a tooltip on each button with the shortcut that executes the action. Vanished user e175adb86e72bb96a1706f7ab31b9df8 (talk) 12:38, 28 March 2018 (UTC)

@Micru: The matter doesn't relate to the newest 2017 WikiEditor, which is available as one of the Beta Features. Moreover, the 2017 wikitext editor doesn't have the "Cancel" button. You can discuss this at meta:Tech. Meanwhile, why not experience the beta mode of the feature? Oh, and it was discussed at English Wikipedia previously George Ho (talk) 08:03, 30 March 2018 (UTC)

It does relate to the 2017 WikiEditor. I have it enabled, and now I cannot disable it. Whenever I go to the beta features, I unclick "New wikitext mode", but when I save it is clicked again... Vanished user e175adb86e72bb96a1706f7ab31b9df8 (talk) 08:26, 30 March 2018 (UTC)

I believe you mean the ones seen at w:en:Help:Edit summary, right? George Ho (talk) 09:04, 30 March 2018 (UTC)

No, when you activate the beta feature "New wikitext mode", and then you edit a page, there is a button that says "Publish changes", if you click that button a dialogue appears. Anyway, I want to disable it and now I can't. Vanished user e175adb86e72bb96a1706f7ab31b9df8 (talk) 09:56, 30 March 2018 (UTC)

To which wiki were you referring? I see that you have contributed to Catalan- and English-language wikis, so I can't figure out which one. Either I can help you disable the feature, or you can go to the Support Desk for more help. George Ho (talk) 10:43, 30 March 2018 (UTC)

Does it matter? And what is the point of having this page for feedback if it is not taken into consideration? Vanished user e175adb86e72bb96a1706f7ab31b9df8 (talk) 11:03, 30 March 2018 (UTC)

I re-read the OP, and I'm so sorry about my earlier misinterpretations and misunderstandings. Even though I don't work for WMF, this is no excuse for my earlier error. I hope you'll forgive me for those.

I hate to admit that the "Publish changes" popup is very annoying and should be remodeled.

By the way, if it's English Wikipedia, the enabling/disabling of the feature works fine for me in my area. I just click/un-click the feature, or I can un-click the "Automatically enable all new beta features". Do you see it clicked in your Preferences settings? If so, un-click it, so all boxes are automatically un-clicked (if not, then un-click all boxes), and then save your settings. George Ho (talk) 11:29, 30 March 2018 (UTC)

You are excused, sometimes it is not easy to figure out what is meant just from text alone.

I tried in en-wp, and in wikidata and in both cases I can unclick "New wikitext mode", but then when I save it is clicked again.... Vanished user e175adb86e72bb96a1706f7ab31b9df8 (talk) 12:32, 30 March 2018 (UTC)

You can disable the editor by the also removing the flag from the checkbox that gives you all the new Beta Features automatically. (It's a known bug.)

Re: the Save your changes bit, there are complex design evaluations that you can read about in Phabricator, and https://phabricator.wikimedia.org/T189803 appears to be an interim solution that should be applied soon. Elitre (WMF) (talk) 15:09, 11 April 2018 (UTC)

Thanks for your message! I was able to disable the NVE for now. I hope the issues get solved. Vanished user e175adb86e72bb96a1706f7ab31b9df8 (talk) 20:13, 13 April 2018 (UTC)

Cancel button needed?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

If all old WikiEditors have the "Cancel" button, why not the newest editor? To cancel my edits, i.e. exit the editor, I just have to click either "Article" or "Back" (and then "Discard My Edits" if I seemingly haven't undone the changes yet). George Ho (talk) 08:52, 30 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Needed help with adapting a gadget to work with the 2017 wikitext editor

Hello! I work on adapting ruwiki's popular Wikifier script to 2017 wikitext editor (see also phab:T156025), and I have not succeeded even with the very basic things like adding buttons to the toolbar and getting access to the wikitext being edited. Usually I'm much more quick at learning new features, but for some reason this is not the case. Reading https://www.mediawiki.org/wiki/VisualEditor/Gadgets as well as trying out the example scripts didn't help much – the examples just don't work for me for some reason. I've not found documentation at doc.wikimedia.org too. Jack who built the house (talk) 18:15, 3 April 2018 (UTC)

@Matma Rex could you help? Jack who built the house (talk) 19:25, 3 April 2018 (UTC)

Okay it seems I've found the problem – I've executed the code after I opened VE, not before. Seems rather counterintuitive, at least after you work with WikiEditor and stuff. Jack who built the house (talk) 20:13, 3 April 2018 (UTC)

Glad you figured it out. The visual editor toolbar (and new wikitext editor too) is only created once when the editor is loaded, and it is not magically updated if new tools are registered.

When testing new scripts, you can click "Read" and then "Edit" again to reload the editor, that's faster than refreshing the page. Matma Rex (talk) 22:11, 4 April 2018 (UTC)

@Matma Rex another question that is crucial for the gadget is: is there a way to work with wikitext from the visual mode? I.e., you press a button, wikitext is changed, then the visual representation is changed accordingly. It would be a possibility for the gadget to handle easily situations like: we have code

"[[link]]"

we need to get

«[[link]]»

In the visual mode, even if we manage to work with the elements like w:User:ערן/veReplace.js script does, two quotation marks and the link would be in three separate elements and it would be extremely hard to handle this correctly. Jack who built the house (talk) 13:41, 5 April 2018 (UTC)

No, the visual editor is not a wikitext editor, it generates HTML which the Parsoid service converts to wikitext.

I would recommend using ve.dm.Document#findText to match quoted sequences (e.g. /"[^"]+"/), then checking to see if there is a covering link annotation using ve.dm.SurfaceFragment#getAnnotations. ESanders (WMF) (talk) 12:04, 7 April 2018 (UTC)

missing preview

Tracked in Phabricator
Task T153306

I'm missing the preview option in this editor. I know it is possible to switch-over to the visual mode, but that is not the same.

1. First, the visual editor can only show an entire document, not a single section. It is therefore not possible to edit a section with the new wikitext editor and have a preview thereof. Starting the text editor in a section and then changing to the visual editor is only possible with the loss of all the amendments.
2. The layout in the visual editor is not the layout of the final document, especially when tables and images are involved. Further, links produced with templates cannot be tested. I tried it, for example, in de:Welterbe in Indien where each line is generated by a template. The visual editor therefore is not a suited replacement for the preview. Bjs (talk) 20:11, 5 April 2018 (UTC)

Hi Bjs,

In the save dialog there is a 'show preview' button, we are considering ways to make it more prominent. The 2017 wikitext editor does support section editing and previewing within that. The visual editor does still not yet support section editing (T50429), so if you switch to VE it will go back to the full document. ESanders (WMF) (talk) 11:56, 7 April 2018 (UTC)

Thank you for the hint, that works fine, also with editing only a section. But, it should really be made more prominent. it is not very intuitive that you first have to press publish before you can select a preview. The selections publish/preview/view changes should be on the same level.

(I'm using German as interface language so i don not know whether the expressions are exactly as above in the English interface, but it should be clear what i mean) Bjs (talk) 13:26, 7 April 2018 (UTC)

Copying using drag and drop

Tracked in Phabricator
Task T192605
Resolved

Generally, it is possible to make a copy of a text passage using drag and drop and pressing the CTRL key while moving the mouse. In this case, a + appears next to the mouse pointer. In the 2017 wikitext editor the + also appears next to the mouse pointer, but the text is moved, not copied (it is deleted from the old position). Bjs (talk) 13:36, 7 April 2018 (UTC)

Interesting, never knew about that shortcut. I doubt the average user even knows it exists, and even then, Ctrl + C , Ctrl + V is generally way faster than a combo of keyboard and mouse.

Personally, I prefer Linux's approach to copy paste, simply select and middle mouse click to paste. Either way, it seems reasonable to add that functionality, assuming that it isn't complex do to so. 197.218.81.60 (talk) 07:40, 8 April 2018 (UTC)

Ctrl + C , Ctrl + V is also a combo of keyboard and mouse, even more keyboard, and mouse to the same extend (i.e. moving from the start position to the target position) Bjs (talk) 20:29, 13 April 2018 (UTC)

I normally select text with no mouse/pointer at all. At least on my Mac, you hold down the shift key while pressing the arrow keys to select text. I find it to be faster and easier than using a mouse, but other people might prefer other options. Whatamidoing (WMF) (talk) 21:58, 19 April 2018 (UTC)

One can actually copy and paste without a mouse since ancient times when Windows / Mac OS and the mouse / trackpad, et al didn't even exist. Heck one can operate any good application or operating system without any mouse at all, in fact, one can even copy and paste without even the mouse or keyboard or similar device.

Anyway, this thread makes the incorrect assumption that this actually works in all operating systems.

It doesn't... 197.218.89.185 (talk) 20:21, 26 April 2018 (UTC)

But that is no reason to inhibit it in operating systems in which it actually works and can be used with the old source editor of Wikipedia. By the way, is there any statistics in which operating systems Wikipedia is edited most? Bjs (talk) 09:11, 27 April 2018 (UTC)

That depends on what you mean by "editing", and where "Wikipedia" is. At the German Wikipedia, I would expect most edits that are not made in a flagged bot account to be done on Windows computers. For some small Wikipedias in developing countries, the most common OS for "fully manual" edits (i.e., not using AWB or similar scripts) might be Android. Whatamidoing (WMF) (talk) 19:51, 7 June 2018 (UTC)

And I thought everybody knows this. IKhitron (talk) 09:18, 8 April 2018 (UTC)

What web browser and operating system are you using? Whatamidoing (WMF) (talk) 17:56, 13 April 2018 (UTC)

Windows 7 (home) and 8 (office), Mozilla Firefox 59.0.2 Bjs (talk) 20:27, 13 April 2018 (UTC)

Slow typing on large pages

Tracked in Phabricator
Task T197652

Exactly what it says. There can be a serious lag when typing on long pages like w:Wikipedia:Village_pump_(proposals). Ed ^{[talk] [en:majestic titan]} 16:10, 14 April 2018 (UTC)

yes the problem is there +1 Ranjithsiji (talk) 03:04, 19 April 2018 (UTC)

Are you sure that the page has finished loading? Are you trying to edit the whole page or just a section? Whatamidoing (WMF) (talk) 21:56, 19 April 2018 (UTC)

@Whatamidoing (WMF) it's loaded, and I was trying to edit the full page. :-) Ed ^{[talk] [en:majestic titan]} 02:19, 20 April 2018 (UTC)

Hey, I'd appreciate if you followed How_to_report_a_bug. We clearly need more info if we're to report anything (I can't reproduce, so what's different between us?). TYVM! Elitre (WMF) (talk) 15:44, 26 April 2018 (UTC)

@The ed17, is this still happening? Elitre (WMF) (talk) 10:20, 24 May 2018 (UTC)

@Elitre (WMF) It is. I'm using Windows 10/Chrome with a pretty decent computer. I've just tried to type eight words in quick succession when editing that village pump page, three different times, and it is taking up to ~thirty seconds for all of the words to appear. Shorter pages like w:HMS Dreadnought (1906) also have a delay, but it's more like input lag (not even a second's delay).

(Edit: This happens with and without the wikitext syntax beta feature enabled.) Ed ^{[talk] [en:majestic titan]} 21:39, 27 May 2018 (UTC)

30 seconds ? that is insane... For me it is near instant. Can you try when starting from this page (disables your gadgets and userscripts) ?

If that isn't any better, can you start up an Incognito/Privacy mode window of Chrome ? That will disable all chrome extensions, when you use Wikipedia, and exclude that it is possibly an issue with a browser addon or something. —TheDJ (Not WMF) (talk • contribs) 11:52, 20 June 2018 (UTC)

I've also experienced a delay in displaying typed characters (delay of about perhaps one second, depending on typing speed), e. g. on the page w:de:Berlin, when editing the whole page (the page was fully loaded before I began typing). If I used the old wikitext editor, the problem did not appear. X black X (talk) 11:58, 11 June 2018 (UTC)

Editor fails to load when trying to "Submit an edit request" on a template protected page

Tracked in Phabricator
Task T184786

Steps to reproduce

1. Try to source edit the template protected page,en:Template:Static_IP, without the "template editors" right. This should display the "This page is currently protected ... message which should also contain the "Submit an edit request" button.
2. Tap on the "Submit an edit request" button.

Expected results

The editor loads for creating a new section with the pre-filled topic "Template-protected edit request on DD MONTH YYYY" and some content in edit box.

Actual results

The editor fails to load showing the "The editor will now load. ... message. The browser's console shows the error "TypeError: Argument 1 of Window.getComputedStyle is not an object." for the mangled code line var l = window.getComputedStyle(t).

Further, if the page is re-loaded using the link found in the message displayed in the page, a different page is loaded which appears to be in an inconsistent state as the UI contains parts of both the 2017 wikitext editor and the OWE. Kaartic ^[talk] 08:53, 20 April 2018 (UTC)

I believe that the seemingly "inconsistent state" of the icons is the result of https://phabricator.wikimedia.org/T191031, which changed the 2010 WikiEditor's toolbar yesterday. Whatamidoing (WMF) (talk) 19:24, 20 April 2018 (UTC)

I'm not pretty sure how this issue is related to the one in T184786. IIUC, this issue is about editing the talk page corresponding to a template protected page, with pre-loaded content and the issue in T184786 is about creating a protected page. Regardless, the errors I see in the browsers console for both the issues are the same.

I didn't refer to the icons in the edit toolbar when I said "inconsistent state" (They don't appear to be using OOUI, at least not yet). See this screenshot.

I noted another surprising thing just recently. When I turn off the "Wikitext syntax highlighting" beta feature, a partial inconsistent state is seen. To add to the surprise, the text in the OWE editor window is syntax highlighted despite the fact that I turned off the beta feature.

Note: I corrected the link for "source edit" in the topic description. Kaartic ^[talk] 05:35, 21 April 2018 (UTC)

(Removed note that belongs in some other thread) Whatamidoing (WMF) (talk) 18:28, 18 June 2018 (UTC)

I don't think that's a relevant reply for this discussion. Anyways, the editor seems to behaving gracefully now. It loads completely instead of halting in an inconsistent state. It shows a Javascript error anyhow. Kaartic ^[talk] 18:47, 18 June 2018 (UTC)

preview and browser support

Tracked in Phabricator
Task T153306

With this change, I find the process of previewing changes more cumbersome than before. In the visual editor, the preview is not used that often. Here multiple review cycles are typically part of the editing. While this is the case, please make sure they're not more complicated to use.

Besides that, I got a complaint that my browser is not supported. My browser is a Firefox clone called PureBrowser.

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 PureBrowser/52.7.3 Tzafrir (talk) 19:17, 29 April 2018 (UTC)

@Deskana (WMF), anything we can do about PureBrowser not being supported? Elitre (WMF) (talk) 14:33, 2 May 2018 (UTC)

@Elitre (WMF) To be brutally honest, no. Only a limited number of browsers can be supported. If it's a clone of Firefox, then I would imagine most things would work, but that cannot be guaranteed. Dan Garry, Wikimedia Foundation (talk) 16:29, 2 May 2018 (UTC)

I also wonder if there may be other issues at play that aren't necessarily connected to the browser. (in case, Help:Locating broken scripts could help.) Elitre (WMF) (talk) 16:40, 2 May 2018 (UTC)

Preview on discussion pages?

Hi! I've used this new wikitext editor during the last weeks, and most have been pleasant surprises – automatic source templates, ease of editing (all the code visible with no code framing) and speedy moves between VE and this editor (to and from). But I (macOS 10.12.6, Google Chrome 66, Vector skin) cannot seem to get the preview to function when on discussion pages. Often there is a hard freeze, making me have to exit the edit process and start the edit anew. Is this a bug? I'm working on svwp, where Flow hasn't been added to the interface. Paracel63 (talk) 15:42, 25 May 2018 (UTC)

I have also faced this problem, so it appears on different computers, operating systems and browsers (the only difference, by the way: I constantly faced slow moves between visual editing and 2017 wikitext editor, especially in the direction from 2017 wikitext editor to visual editing). X black X (talk) 11:20, 28 May 2018 (UTC)

OK. My experience of time when changing editor is 2 seconds on small pages (either way to/from) and 5 seconds on large pages (either way). My computer is MacBook Air (8 GB RAM, Intel Core i7 2.2 GHz), delivered last November. Paracel63 (talk) 19:08, 28 May 2018 (UTC)

On small pages I experience about the same, but on medium to lage pages, only a change from visual editing to 2017 wikitext editor is performed in about 5 seconds, a change from wikitext editor to visual editing takes about 9 seconds. Under such conditions, I'd stay in wikitext editor mode to complete the edit and neglect visual editing. X black X (talk) 23:26, 28 May 2018 (UTC)

I can't reproduce this on Paracel's user talk page at this wiki or at the Swedish Wikipedia. I also tried an article talk page, and I was able to see the preview. I tested in Safari 11.1 on macOS 10.12.6.

Questions:

1. Have you enabled the Visual Diffs beta feature?
2. How are you trying to start the preview (e.g., keyboard shortcut or opening the Publish dialog?) Whatamidoing (WMF) (talk) 04:12, 6 June 2018 (UTC)

Hi! I haven't enabled any other beta features (didn't know they were connected). I'm normally hesitant in being a beta tester, but this new wikitext feature is enough bug free to be useful. Two other observations:

1/ When in editing mode, previewing, returning to editing, and then publishing, this last action seem to bypass the Publish dialog altogether, not giving me the possibility to add a publication comment.

2/ When editing a discussion page, the Publish comment field seem to be unreachable.

I most often use the keyboard shortcut to get to the preview, most often using the buttons to navigate from the Publish dialog. Paracel63 (talk) 17:27, 6 June 2018 (UTC)

(I'm not an early adopted either. In fact, my team is used to me telling them that Change Is Bad.  :-)

When I enable the 2017 wikitext mode and open https://sv.wikipedia.org/wiki/Användardiskussion:Paracel63?veaction=editsource&section=45 (the last section on your userpage), add some text, and type Control+⌥ Option+p, I get the preview. Preview also works when I click on the blue Publish changes… button, and then on the preview. I've tested this in macOS 10.12.6 in both Safari 11 and Firefox 60. Is that broken for you, on your talk page at the Swedish Wikipedia, in Chrome? Whatamidoing (WMF) (talk) 19:38, 7 June 2018 (UTC)

Hi! My bad (memory). No, it works here too. There are other glitches, but they're not serious. Have a nice day. Paracel63 (talk) 11:14, 11 June 2018 (UTC)

I've tested showing the preview on talk pages (on non-macOS) again and this time it worked, so this problem seems to be solved. X black X (talk) 11:50, 11 June 2018 (UTC)

Bugs that magically disappear make me nervous (because maybe they'll magically come back, too). But I'm going to hope for the best. Do please post again if this bug re-appears in the future. I'd really appreciate it. Whatamidoing (WMF) (talk) 19:20, 11 June 2018 (UTC)

I don't have time to thoroughly test all combinations:

*editing article space, discussion, other pages

*starting on VE or Wikitext 2017

*previewing through button or shortcut

*navigating through the four Wt17 preview space buttons: return to edit, review edit, return to publish dialog, publish

*navigation through the above in reverse or alternative order

*other combinations

Things are bound to change depending on situations. In some instances the publish button goes straight to publish, not presenting the publish dialog in between. Some other day I'll return with the exact circumstances, but as of now it seems to be random, or a consequence of some of the 200 possible combinations elaborated above. Paracel63 (talk) 21:17, 11 June 2018 (UTC)

The Publish button goes straight to publishing only when you're in a preview or diff screen. (That way, you can type your edit summary, double-check your edit, and not have to go backwards to look at your edit summary again. If you want to go back to the edit summary, then click the "Return to save form" in the lower left.) Advice on improving the design is always welcome. Whatamidoing (WMF) (talk) 16:52, 12 June 2018 (UTC)

Thanks. Yes, that seems to be the behaviour I'm trying to get the hang of. It isn't consistent with earlier system behaviour, but maybe it's a better solution (edit summary is not everything). Paracel63 (talk) 20:12, 12 June 2018 (UTC)

Conflict with Wikitext syntax highlighting beta feature

Tracked in Phabricator
Task T199740

When I turned on the Beta Wikitext mode, the bold text and the big text from the Wikitext syntax highlighting feature disappears, in both English and Chinese Wikipedia. It doesn't affect the italics though.
Without the new Wikitext mode
With the new Wikitext mode Wei4Earth (talk) 04:30, 27 May 2018 (UTC)

The syntax highlighting team has made a few improvements. Is this still a problem? Whatamidoing (WMF) (talk) 22:35, 13 July 2018 (UTC)

Yes, this problem still exists. @Whatamidoing (WMF) Wei4Earth (talk) 17:12, 16 July 2018 (UTC)

Thanks. I've filed a bug report. Whatamidoing (WMF) (talk) 19:09, 16 July 2018 (UTC)

Make show changes and peview available by one click

To show the changes made or show the preview, one has to click on the blue button to open the publish changes dialogue and the click the check/show changes button or the preview buton in the dialogue. For users often using the show changes function or the preview function it's annoying to have to do two clicks where only one click is needed now. Therefore it should be made possible to optionally have such buttons in the toolbar. This could be done by choping the blue button into three smaller buttons (two grey and one blue) as we have them in the standard wikitext editor. X black X (talk) 12:19, 28 May 2018 (UTC)

I understand the desire, but there's a limited amount of space in the toolbar. Adding two more buttons means that the toolbar will wrap on to two fat lines for even more users. In the meantime, you might be interested in the options at w:de:Hilfe:Tastaturkombinationen, which should also work in VisualEditor's wikitext mode. Whatamidoing (WMF) (talk) 04:18, 6 June 2018 (UTC)

Edittools (HTML entities, tags, matching character combinations)

In the 2017 wikitext editor, the MediaWiki:Edittools aren't available. These Edittools, or their project specific versions like w:de:MediaWiki:Onlyifediting.js (in combination with w:de:MediaWiki:Edittools) or w:en:MediaWiki:Edittools, offer several elements that are not available in the 2017 wikitext editor, like the entity  , the tags <nowiki></nowiki> (also combined to <code><nowiki></nowiki></code>), <includeonly></includeonly>, <noinclude></noinclude>, <onlyinclude></onlyinclude>, or matching character combinations not available in the "often used" section of the character menue (in de-wikipedia e. g. “” and ‘’) and much more. These featueres should be made availabe in the 2017 wikitext editor, either by using Edittools, or on a different way. Beyond that, also elements like <br />, {{}} (for parser function and variables as they can not be added by the Template wizard) and {{{}}} (for parameters) would be helpful. X black X (talk) 13:26, 28 May 2018 (UTC)

The "Often used" section of the special character menu is under local control, so the local community can add whatever they want.

Generally speaking, VisualEditor's wikitext mode is "tuned" for article editing, so the team is hesitant to include elements that should not be used in typical Wikipedia articles. If you frequently create templates, then you may be more satisfied with an editing environment that is optimized for that kind of work. (The "old" wikitext editor is still available for one-time edits, even with the beta feature enabled; just change the end of the editing URL to say &action=submit instead of &action=edit).

(I see that you have found T164956 about the line breaks.) Whatamidoing (WMF) (talk) 20:01, 7 June 2018 (UTC)

The "Often used" section is the same in the VisualEditor and in the 2017 wikitext editor. To include tags there would probably not be such a good idea, as VisualEditor is intended for WYSIWYG-editing. It would be good, to have a menue especially for the 2017 wikitext editor or a 2017-wikitext-editor-specific extended version of the "Often used" section to place the HTML-entity   or tags like <nowiki></nowiki> or <code><nowiki></nowiki></code> there. Thank you for telling me the possibility to change editor via URL-modification. In the de-wikipedia it only works, when one has disabled the VisualEditor during it's Beta-Phase in ones settings (only then, one get's the old wikitext editor, if one replaces "veaction=editsource" or "veaction=edit" in the URL by "action=edit"). X black X (talk) 21:54, 8 June 2018 (UTC)

Pages transcluded onto this page

This is something that I have been using in the previos wikitext editor. Do we have this available in the 2017 wikitext editor ? Satdeep Gill (talk) 10:25, 6 June 2018 (UTC)

I don't think so. It's been discussed, but I can't find a Phab ticket right now. However, they're all listed on the info page (example). Whatamidoing (WMF) (talk) 22:42, 13 July 2018 (UTC)

In Special:Preferences the 'Preview' sub-section doesn't make sense

Tracked in Phabricator
Task T197487

With the 2017 wikitext editor enabled, I think the preferences in the 'Preview' sub-section of the Editing section don't make much sense.

Something should be done about this. Possibly noting that this only applies to OWE or completely hiding those preferences when 2017 wikitext editor is enabled. Kaartic ^[talk] 19:23, 13 June 2018 (UTC)

Hi there,

Good point. I've filed this as https://phabricator.wikimedia.org/T197487. Jdforrester (WMF) (talk) 17:51, 15 June 2018 (UTC)

Ctrl+C/Ctrl+X causes wikitext editor view pane to jump to top in Edge

Running Microsoft Edge, Windows 10 1803 (17134.112), Vector/default wiki skin. Problem also occurs in InPrivate session (signed out, no extensions, etc).

To reproduce, edit a large article so that the scroll bar is showing within the wikitext editor view pane. Scroll down a little. Copy or cut any text within the editor using the keyboard shortcuts.

Only occurs if syntax highlighting is enabled. NeoGeneric (talk) 10:54, 18 June 2018 (UTC)

This sounds a bit like a bug that @MusikAnimal (WMF) was chasing down a little while ago. Do you have problems only when cutting or copying, or does it scroll inappropriately at other times, too? Whatamidoing (WMF) (talk) 21:18, 13 July 2018 (UTC)

I only noticed it jumping when cutting or pasting. However, I have since disabled syntax highlighting in my browser as soon as it became an issue. NeoGeneric (talk) 11:31, 14 July 2018 (UTC)

Ehancement: Semi-automated/ tool assisted 'fixup' editing ....

I've recently been using the 'New wikitext mode' so I have access to it's enhanced syntax highlighting.

What would also be appreciated in terms of my "repair" edits would be integration of the search regexps that the tool here Wikipedia cleaner has for identifying CHECKWIKI repairs., There are other semi-automated edit scripts like auto-ed that would also be useful.

I'd also like to see consideration given to integrating something like User:PerfektesChaos/js/lintHint, given that it's currently not compatible with the mode. ShakespeareFan00 (talk) 19:26, 6 July 2018 (UTC)

Thanks for the suggestions. I think @NicoV is the best person to ask about whether WPCleaner can be made to run in this kind of environment. As for @PerfektesChaos's script, it's possible to install editing gadgets, but I don't know how easy it would be. Whatamidoing (WMF) (talk) 21:08, 13 July 2018 (UTC)

Hi. As WPCleaner is developed in Java, I see no wa to integrate it with the new wikitext mode. It would probably require developing a new gadget following the line given by Whatamidoing. NicoV (talk) 07:24, 14 July 2018 (UTC)

• It is a CodeMirror issue.
• 2017 VisualEditor source mode is involved only by serving a button, but 2006 or 2010 toolbar would have done the same with the similar button.
• On CodeMirror mode the original textarea does not contain the updated wikitext, and it needs to query from the CodeMirror architecture to retrieve the last updated wikitext.
• This weekend I deployed lintHint supporting both wikEd gadget and CodeMirror extension.
• Has been announced at w:de:user talk:PerfektesChaos/js/lintHint #Reporting incompatibility of LintHint.js with 'New wikitext mode' in Beta.
• It does not only evaluate the updated highlighted wikitext but also succeeds in positioning to the source text fragment in doubt.
• VisualEditor itself is not involved in linter business nor lintHint, since there is no wikitext present at client side. PerfektesChaos (talk) 20:55, 14 July 2018 (UTC)

And this update is activated how? I assume the documentation will also be updated? ShakespeareFan00 (talk) 22:24, 14 July 2018 (UTC)

I do follow a standard procedure:

• If it is a real bug, even more damaging texts, it is remedied and deployed asap.
• If it is a little improvement, it is published in debug state and a small group of test users will deal with that for half a day or a day.
• If there are no complaints a small step will be deployed then for all.
• If the step is very minor and makes no real change for users, deployment to all might be postponed and follows later together with more effective changes.
• If it is a quite big change with some risks (like the issue which is discussed here) the preliminary change will be published for a week before it is deployed to all.
• If that turns out to be stable and it is a major issue worth mentioning in documentation, it will be added one or two weeks later if no problem arrived.

Therefore it might take a month between a suggestion and the documentation of a change.

The update is performed by uploading new JS page contents. If browsers and servers would obey cache intervals it might take further days up to a week. PerfektesChaos (talk) 11:01, 15 July 2018 (UTC)

kde je shrnutí?

Uživatelský agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

URL: https://cs.wikipedia.org/wiki/Lehovec Nolanus (talk) 16:56, 30 July 2018 (UTC)

Do you want Help:VisualEditor/User guide/cs#Zveřejňování změn ? Whatamidoing (WMF) (talk) 20:40, 30 July 2018 (UTC)

Při kliknutí na Zveřejnit změny, funguje to jako ve vizuálním editoru. Martin Urbanec (talk) 11:38, 31 July 2018 (UTC)

Preview changes

Firstly, to clarify my perspective: I edit in code only and feel very uncomfortable with the visual editor. In this version, the editing experience itself is pleasant enough, but the lack of a preview button below the text box drove me crazy. Also the preview option that comes up when trying to save changes doesn't reflect the actual appearance of the page, since it hides all the menus and expands the article to full view. I eventually found myself clicking "save changes" repeatedly just to get to the preview button, didn't feel like the preview actually gave me a preview, then clicked "continue editing" to get back, only to fix a minor problem and repeat the process. Joalbertine (talk) 21:45, 19 August 2018 (UTC)

+1 for the need to have a preview button. It would save a lot of time and effort. Binabik (talk) 18:50, 25 August 2018 (UTC)

Yes please, having preview button inside of save changes is counter intuitive and costs many clicks. Also preview is much wider than real web page (with column on left side and small offset on right side) which makes layout of page a bit offset. KasciJ (talk) 19:18, 26 August 2018 (UTC)

This has been a popular request, but the team hasn't figured out how to implement it sanely. There is very little space on the toolbar (especially for users with smaller screens or who have zoomed in a bit to make it easier to read), so they'd like to make a solution that works but doesn't cause the toolbar to run onto two lines.

In the meantime, you might want to learn the keyboard shortcut. It's Ctrl+⌥ Option+p in most web browsers on macOS, and the equivalent on other systems (the meta keys change between browser/OS). The Escape button will let you close the box without needing to take your hands off the keyboard (just don't accidentally press it repeatedly, because that's also the keyboard shortcut for canceling your edit).

The wider preview may be more 'feature' than 'bug', because different people have different screen sizes. If you design something to look perfect on your screen/with your font size, it will look worse on everyone else's. Whatamidoing (WMF) (talk) 17:50, 31 August 2018 (UTC)

I saved page without filling commit text twice. Preview mode must not allow to save changes for that reason. User doesn't see commit text. There are two solutions for the problem.

1. Remove save button. from preview mode
2. Add changes description text entry near the button. D6194c-1cc (talk) 19:35, 6 October 2018 (UTC)

Bug when deleting revision

I am a sysop on fr.WP and found out that when deleting revision, the wikitexteditor automatically launches itself (after submitting the revision deletion), rather than showing the confirmation message. Tried with &safemode=1, same thing. Binabik (talk) 18:59, 25 August 2018 (UTC)

I wonder whether this might be the same (underlying) problem as phab:T176022. If so, then it might be fixed soon. I've pinged you in that task. Whatamidoing (WMF) (talk) 00:13, 13 November 2018 (UTC)

Invisible spaces

Tracked in Phabricator
Task T220154

When using new editor, is hard to recognice leading space in page https://cs.wikisource.org/w/index.php?title=Ottův_slovník_naučný/Výrov&type=revision&diff=172080&oldid=172079&diffmode=source JAn Dudík (talk) 19:41, 27 August 2018 (UTC)

Unable to edit redirect

Tracked in Phabricator
Task T178976

I wanted to edit page which is redirect. So I click to [edit], but instead of editing source of redirect the target page source started to load JAn Dudík (talk) 19:03, 28 August 2018 (UTC)

Empty page

Sometimes I write new page, copy text to clipboarrd and then click to [publish], new page is created but without text.

when I want to re-publish it, new lines appears between https://cs.wikisource.org/w/index.php?title=Ottův_slovník_naučný/Výstředník&diff=172789&oldid=172788&diffmode=source JAn Dudík (talk) 21:03, 2 September 2018 (UTC)

Try "Paste and Match Style" (or whatever your computer calls it) to avoid the unnecessary newlines. Sometimes text copied to the clipboard is not completely plain text. Whatamidoing (WMF) (talk) 21:05, 4 April 2019 (UTC)

I suppose that from editing textarea should be copied plain text to clipboard.

Maybe beter description how to reproduce (7 months ago):

• Write new page with WE2017
• select all, ctrl+c
• [publish]

Empty page

• edit again
• ctrl+v

Page with extra lines JAn Dudík (talk) 05:33, 5 April 2019 (UTC)

It's not an HTML textarea. It copies rich text. Whatamidoing (WMF) (talk) 18:36, 5 April 2019 (UTC)

Special characters mis-rendering

I am having problems entering [[ ]] & {{ }}. The first character of [ renders okay, putting in a second [ changes the first to a ʽ. Putting in the first ] works okay, putting in a second ] changes the first to a ʼ. Putting in a { creates that character with a squiggly line at the bottom, something like a "3" character lying on its left side & inserts a new line after the cursor. Entering a second { creates another "3" character lying on its left side (leaving the first { with its sideways "3"), but I cannot select it with my mouse cursor or put it to the right of this character if it is at the end of the line. Entering a < sometimes backspaces over the previous character & then displays a | symbol. Entering > seems to work as normal.

I am experiencing this on Firefox 61.0.2 (64-bit) running on Windows 10 Home version 1803 build 17134.228. I have also observed this on MS Edge on Windows 10 & similar problems with Chrome in desktop mode on my iPhone 6+. I do not have problems with [[ ]] on Internet Explorer on Windows 10, but entering { does & displays nothing. Peaceray (talk) 04:40, 4 September 2018 (UTC)

Peaceray, are you still having this problem? Did you accidentally enable the IPA keyboard? Whatamidoing (WMF) (talk) 18:48, 26 October 2018 (UTC)

Citation wizards not supported

This editor does not support the wizards for filling out the cite book, cite news, etc., templates that I rely on heavily. So it's unusable to me, sadly. Sandstein (talk) 19:00, 10 September 2018 (UTC)

Sandstein, which wizards are you using? Is the (built-in) citoid service (toolbar > Cite > Automatic) not working for you? Whatamidoing (WMF) (talk) 17:56, 19 September 2018 (UTC)

Thanks - I didn't find that function. But it doesn't work how I want it to either. It only allows fully automatic or fully manual filling out of citations. It does not support filling out what it can automatically, and letting me fill out the remaining fields, which is how I've worked so far. Sandstein (talk) 18:23, 20 September 2018 (UTC)

You can do that. Start with the automatic form, click "Insert" to add it to the page.

In the visual mode, you can then click "Edit" to fill in the remaining fields (or to fix the ones that were wrong) in a dialog box. In the 2017 wikitext mode, you can manually edit the wikitext. Whatamidoing (WMF) (talk) 19:45, 20 September 2018 (UTC)

John Cline (talk) 09:23, 18 November 2018 (UTC)

Error message

There is a bug with the advanced wikitext editor that prompts a message reading, "Something went wrong. Error saving data to server: Empty server response" at times when making an edit to certain articles. I've had this occur multiple times while editing the "2018 in American television" article. For some reason, the edit will be saved anyway after it displays said message, but this only appears when you press the article tab and then refresh the page in which the error message appeared.

Also, it mistakenly identifies any edit the user makes themselves as a edit conflict if they attempt to publish the article changes again once the "save changes" dialog box is triggered, when that is only supposed to occur when another user on a different IP address concurrently edits a particular section. Tvtonightokc (talk) 15:31, 14 September 2018 (UTC)

Are you still having this problem? Whatamidoing (WMF) (talk) 19:30, 26 October 2018 (UTC)

I have had this issue pop up periodically. I have no idea if all instances occurred while others were editing a different section of the page from the one I was editing at the time. If so, that differs from the standard text editor, which recognizes the section being edited as not being the same as another part of an article being edited by someone else simultaneously, as it should. Tvtonightokc (talk) 15:51, 27 October 2018 (UTC)

I've usually experienced this at Wikivoyage, and I'm pretty sure that nobody else was editing the articles at the same time.

What's your web browser and operating system? I get this in Firefox on my Mac. Whatamidoing (WMF) (talk) 21:50, 9 November 2018 (UTC)

Syntax highlighting of special characters

Tracked in Phabricator
Task T196934

Tracked in Phabricator
Task T85638

https://en.wikipedia.org/wiki/User:Cacycle/wikEd_help#Syntax_highlighting_of_special_characters I would like syntax highlighting specifically of n and m dashes. Can that be added (or am I using it wrong somehow)?

As a note, I am not happy about the Insert drop down ... what I generally want to do takes two clicks to expand that list. Can we have an option to have it expand fully first time? PopularOutcast (talk) 21:19, 21 October 2018 (UTC)

The teams that built these two tools (CodeMirror's syntax highlighting and the visual editor) are not working on these areas at the moment, so (unfortunately, but realistically) I wouldn't expect to see much progress this year. However, the ideas are on their lists, and the syntax highlighting idea might be suitable for the m:Community Wishlist, which starts on Monday. Whatamidoing (WMF) (talk) 18:31, 26 October 2018 (UTC)

Suggestions

Tracked in Phabricator
Task T221029

Tracked in Phabricator
Task T221032

Tracked in Phabricator
Task T153306

I have been using WikEd for years now. The wikitext is progressing well imho but I do miss a few things before switching: a more detailed/advanced toolbar, choosing the font and its size as well as a rapid access to the templates and a "show preview".

Here are a few suggestions

- Allow a "ctrl+click" on a template while editing to open its template page in an other tab

- a toggle between a "simple/basic" toolbar (single row) and an advanced toolbar (2 rows with direct access to search and replace, browse menu per section, expanded "style text" menu...)

- A simple way to increase font size and, if possible, the font itself (via user preferences? and if possible with dedicated CSS to avoid interactions with users' site-wide custom CSS preferences)

- Direct toolbar access to show preview (without having to go through "publish changes" and then "show preview")

I am not a coder. So I don't know if these suggestions are realistic or not. :-) Afernand74 (talk) 09:38, 2 November 2018 (UTC)

@JKlein (WMF), what do you think of this idea of having two separate toolbars (normal vs advanced modes)? You can see a screenshot from WikEd's super-complex toolbar at File:WikEd screenshot.png. Whatamidoing (WMF) (talk) 19:39, 15 April 2019 (UTC)

WikEd

Hey, just thought I'd let you know that the new editor breaks wikipedia:WP:WikEd, a wikitext editor many find very helpful. It has a ton of editing tools, including a RegEx search that makes cleanup of articles go a lot faster. If this editor is made the default, can you guys do something to make sure it is either still able to be disabled, or make sure it doesn't suppress WikEd from appearing in the edit pane? Thank you! Cymru.lass (talk) 21:48, 4 November 2018 (UTC)

• I think that I can safely promise that there will always be a way to switch editing environments. Otherwise, some people wouldn't be able to edit (e.g., if you use a screen reader, or you're working on a very old computer).
• The 2017 wikitext editor also supports RegEx search, plus things like syntax highlighting. What tools do you find that you're using in WikEd that don't seem to be generally available? Whatamidoing (WMF) (talk) 02:39, 7 November 2018 (UTC)

@Whatamidoing (WMF) See my previous comments

- A simple way to increase font size and, if possible, the font itself (via user preferences? and if possible with dedicated CSS to avoid interactions with users' site-wide custom CSS preferences)

- Allow a "ctrl+click" on a template while editing to open its template page in an other tab

- an advanced toolbar (2 rows with direct access to search and replace, browse menu per section, expanded "style text" menu...)

- Direct toolbar access to show preview (without having to go through "publish changes" and then "show preview")

- Better syntax highlighting

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Editing#Syntax_highlighting_of_special_characters

- Collapsible code templates to improve readability ("code folding")

https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Editing/Minimize_references

Bringing eventually wikitext to feature parity with WikEd would be nice. But first graduate it :-)

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Editing#Graduate_2017_wikitext_editor_and_make_it_a_full_value_editor Afernand74 (talk) 10:25, 10 November 2018 (UTC)

John Cline (talk) 22:40, 17 November 2018 (UTC)

"wgAction":"view"

VisualEditor/Gadgets#Checking whether VisualEditor is currently open https://phabricator.wikimedia.org/T167880

When actively using the "2017 wikitext editor" to edit a page, the interface is still in "wgAction":"view" mode. Is this intentional?

With Javascript, how to I realize that the interface is in "edit" mode while using the "2017 wikitext editor" to edit a page? For the old editors, I was able to use if(mw.config.get('wgAction') === 'edit'){ /* do something */ }, but that does not work any longer. MisterSynergy (talk) 10:38, 7 November 2018 (UTC)

User:Whatamidoing (WMF), you seem to be moderating these discussions. Can you please help me with my question here? Thanks a lot! MisterSynergy (talk) 14:57, 27 November 2018 (UTC)

I think that the links in the summary by 197.218 will be more useful to you than anything I could tell you. Whatamidoing (WMF) (talk) 19:04, 7 December 2018 (UTC)

Yes this is more or less what I am looking for. It does not really work for me yet, but I think I know meanwhile how to go about it… MisterSynergy (talk) 23:54, 7 December 2018 (UTC)

About automatic quote function

The citation function, type "automatic" of the "beta" function of the "beta wikitext editor" is to mixing/switching the texts. For example, for the IBM about FIPS 140–2 function adds publisher (IBM Knowledge Center) in the title, and add url (www.ibm.com) to work/author...

"<ref>{{Citar web|url=https://www.ibm.com/support/knowledgecenter/pt-br/SSSHTQ_8.1.0/com.ibm.netcool_OMNIbus.doc_8.1.0/omnibus/wip/install/concept/omn_con_fipssupport.html%7C|title=IBM Knowledge Center|work=www.ibm.com}}</ref>". Elilopes (talk) 18:21, 8 November 2018 (UTC)

Thanks for your note. It looks like someone pasted in an invalid URL. It should not end with "concept/omn_con_fipssupport.html%7C".

However, even with the correct URL, the results aren't much different. The HTML in IBM's webpage doesn't specify a name for the website, using any of the standard formats. Therefore, the automatic tool guesses that it's probably "www.ibm.com". The alternative is to leave it blank. Whatamidoing (WMF) (talk) 22:21, 9 November 2018 (UTC)

Using the correct url "omn_con_fipssupport.html", the name for the website or author name appears in the title (titulo=IBM Knowledge Center), reference used in the ptwiki article [https://pt.wikipedia.org/wiki/Federal_Information_Processing_Standard FIPS].

Similar to website techtarget whatis title is "... Definition from WhatIs.com". ~~~~ Eli-Lopes (dúvidas?) (talk) 16:01, 13 November 2018 (UTC)

IBM has decided to make that page on their website be called "IBM Knowledge Center". This is line 233 in the HTML from the page you are looking at:

<title>IBM Knowledge Center</title>

When the citoid service looks at their HTML, it finds the part that IBM has declared to be the page's <title>, and it copies IBM's choice of title into the |title= field for the citation template.

There is no way for the citoid service to guess that IBM has put the "wrong" thing in their page title tag. The only way to "fix" that is to contact IBM and convince them to change the HTML on their page to suit you.

In the meantime, you can fix the citation by editing the template to display the information that you think is proper. Whatamidoing (WMF) (talk) 18:31, 13 November 2018 (UTC)

Ok, i found the problem: IBM website uses a internal frame with title <title>Federal Information Processing Standard 140–2 (FIPS 140–2) suporte</title> at url https://www.ibm.com/support/knowledgecenter/pt-br/SSSHTQ_8.1.0/com.ibm.netcool_OMNIbus.doc_8.1.0/omnibus/wip/install/concept/omn_con_fipssupport.html?view=embed. ~~~~ Eli-Lopes (dúvidas?) (talk) 18:47, 14 November 2018 (UTC)

0 touche pour signer

Agent utilisateur : Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.2 Safari/605.1.15

URL : https://fr.wikipedia.org/w/index.php?title=Discussion:Histoire_des_Juifs_au_Maroc&action=edit&section=new

Bjr. Cela fait plusieurs jours que mon écran n'affiche plus de touche où cliquer pour signer/dater les messages. Je signale que je travaille toujours sous éditeur visuel mais lors de l'écriture de messages, le basculement en code était automatique. Maintenant, il ne l'est plus (tant mieux pour moi) mais impossible de signer. Même si je bascule en code, toujours pas de touche pour signer. Cdmt' Mylenos (talk) 06:55, 18 November 2018 (UTC)

In the 2017 wikitext editor (VisualEditor's wikitext mode), the signature button is in the "Insert" menu. Whatamidoing (WMF) (talk) 20:44, 4 April 2019 (UTC)

Ca marche ! Merci 1000 fois.

(Cela fait des mois que je ne peux plus signer, sauf "à la main")

Merci encore. Mylenos (talk) 11:10, 5 April 2019 (UTC)

Inconsistency of the "Publish changes", "Review changes", "Show preview" and "Resume editing" buttons

See long discussions in https://phabricator.wikimedia.org/T44138, https://phabricator.wikimedia.org/T153306.

Hello,

I think the organization of placing buttons "Review your changes" and "Show preview" and the summary edition within the "Save your changes" overlay is very disconcerting.

I take the following series of action as an example :

• I make some changes to a page and want to review the page before publishing,
• So I click the "Publish changes..." button (which is a first problem : publishing is not reviewing),
• The "Save your changes" overlay appears, I click on "Show preview",
• The pages looks good to me, so I want to see the "Save your changes" overlay again in order to add a summary to my edit,
• As previously, I click the "Publish changes" button again... Fail! The page is published, I didn't had a chance to edit the summary.

Indeed, the "Publish changes" button changes its role depending on the window I'm on. I actually had to hit the "Return to save form" button, and then only the "Publish changes" button. This is the exact same button (apart from the "..." which is not very noticeable), at the exact same position in the window. The "Publish changes" button on the "Save your changes" overlay is different, because is not in the upper-right of the window, but this one is at the exact same position as the "Publish changes..." button.

This is very disconcerting. The same button has various roles.

I think the "preview" button should be actually separated from the "publish changes" button. There should be a "Review you changes" button next to the "Publish changes" button, giving access to both page preview and diff. Then the "Publish changes" button should always give access to the summary editing, no matter the window we are on (except, of course, on the "Save you changes" overlay).

This is my two cents. I think there is still work to do for this new interface to be as efficient as the previous one.

Other concerns for the record :

• We no longer have access to the tags (noinclude, nowiki, etc.), the wikicode (category, etc.) which was very useful for advanced users (I use the editor in "source editing" mode). There should be an option to add them to the interface (if there is one, I never found it).
• The summary editor is now a text box instead of a text line. In browsers, this means we no longer have access to the drop-down history list. This is an issue when we do repetitive work with the same summary: I used to type two characters, then select the message from the list. Usually, my clipboard is used by a text or a template to paste on the code, so I can't use it on the summary.
• Not to mention the fact that, to switch between page editing and page previewing, it takes now two clicks instead of only one before to launch the preview, then one click instead of none to edit again. This seems nothing, but for people like me who generally preview the page lots of times before publishing, this is very heavy in the process of editing.

Thanks for reading this long message. The new editor is good work, but it still need a few refinements to be as efficient as the previous one, this is why I don't use it for now. I tried it a long time, but the issues mentioned above made me disable it as I loose half my productivity. There should be an "advanced" mode I think. Epok (talk) 10:43, 18 November 2018 (UTC)

I began testing the 2017 Text Editor yesterday and thought I'd share some highlights from my first experience.

Initially, I was very confused because I could not find the preview link, I agree with Epok that it is inconsistent with how we've been molded as editors for years up to now. For me, it wasn't until I had uploaded a screenshot and reported what appeared to be an anomaly at en-VPT,[https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=869255939] where I was prepared to publish my posting without previewing it, when I learned that another screen appeared after you pressed "publish changes". I believe that needs to be improved.

It does not intuitive follow that you should press "publish changes" to expose the publishing links one would expect to exist. Considering that one of the buttons in the newly exposed view is another "publish changes" link, the first one encountered could be relabeled to make things more obvious. For example, I suggest that "'''Open publisher'''" would be, and would have been much less confusing,

Thank you for considering this, and for all that you do in support of our needs. John Cline (talk) 15:23, 18 November 2018 (UTC)

> access to the drop-down history list

This will be improved next week (sometime on 11 April 2019 on the English Wikipedia). Whatamidoing (WMF) (talk) 20:46, 4 April 2019 (UTC)

Thanks for this info! Epok (talk) 04:33, 5 April 2019 (UTC)

Need a short personally customizable quick-launch toolbar

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. Timeshifter (talk) 14:25, 18 November 2018 (UTC)

These could all be added to VisualEditor/Special characters, which stays open, if you can convince your community that they are generally needed. Whatamidoing (WMF) (talk) 19:39, 1 March 2019 (UTC)

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). Timeshifter (talk) 21:40, 1 March 2019 (UTC)

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.) Whatamidoing (WMF) (talk) 17:53, 3 March 2019 (UTC)

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. Timeshifter (talk) 13:47, 5 March 2019 (UTC)

Was most of this meant to be posted to the Talk:Talk pages consultation 2019? Whatamidoing (WMF) (talk) 20:21, 5 March 2019 (UTC)

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. Timeshifter (talk) 04:07, 6 March 2019 (UTC)

Reusing edit summaries

Tracked in Phabricator
Task T50274

When entering an edit summary a preview of summary predictions, based on summaries previously entered, should be offered. This is useful when performing a recurring edit like adding a Project banner for a WikiProjet. Right now you must manually enter each edit summary which is considerably more time consuming. Thank you. John Cline (talk) 14:52, 18 November 2018 (UTC)

Make the table generator at least as good as it is now

https://phabricator.wikimedia.org/T209262

I had the opportunity to use the table generator.and was surprised at seeing that it was less functional than the one in current use on en Wiki. I wish it would continue i allowing you to designate n rows and n columns instead of the one size fits all, 1 row 2 column table generated in TE17. I would add, if the build options return, it would be nice to be able to preview the table before inserting it. In my opinion, previewing prior to inserting is always the best method, Thank you. John Cline (talk) 15:39, 18 November 2018 (UTC)

This was deliberate see https://phabricator.wikimedia.org/T113224. It is a tradeoff between speed vs convenience. Some or many people may not appreciate extra dialogs for no good reason. For instance some complain that the link buttons are not that good because they open up a dialog, while others may appreciate the "page finder" functionality. 197.218.90.177 (talk) 18:47, 18 November 2018 (UTC)

Please include an option for using the OpenDyslexic font

I am accustomed to using the OpenDyslexic font when editing and see that it is not available in preferences as an "Edit area font style" for use with the 2017 text editor. It is an accessibility issue for me and I'm sure that it is for some others as well. It would be greatly appreciated if this font could be include as a preference option. Thank you. John Cline (talk) 16:06, 18 November 2018 (UTC)

John, I believe that specific fonts are something that you have to set up in your own web browser. Whatamidoing (WMF) (talk) 20:31, 19 November 2018 (UTC)

Thank you Whatamidoing (WMF) for your reply. On en Wikipedia I modified my Common/CSS page with a verbatim script that was given to me by volunteers at the village pump/technical page in response to a question I'd posted there to these regards. If there is such a thing as a Global/CSS page I would need to create that page and probably modify it with similar changes. My request here was prompted upon noticing the preferences option on the editing tab under "editor" where it says "Edit area font style" and therein the choices of Monospaced font, Sans-serif font, and Serif font are offered. It seems that if OpenDyslexic font was offered there, I could select it and preclude any need for creating or modifying this or that /CSS page which I would not know what to do or where to do it unless I was specifically shown by a tech-savant that clearly has enough on his or her plate already in serving the collective needs of the community such that I relish the thought of increasing their workload by asking that they also find time to serve my individual needs. It would be much better to my manner and belief if it simply was added among the existing choices where I could service my own needs without feeling that I've had to misappropriate our limited technical resources in achieving my desired end. Thank you again. John Cline (talk) 04:27, 20 November 2018 (UTC)

You can copy the contents of https://en.wikipedia.org/wiki/User:John_Cline/common.css into https://meta.wikimedia.org/wiki/User:John_Cline/global.css to get the effect you want at all the wikis.

Wikipedia doesn't know what fonts your computer has installed. Your web browser does, and most of them allow users to specify what fonts they prefer. For example, in Chrome, you go to the settings page and scroll down to the spot that says "Customize fonts" (or paste this into the bar, apparently: chrome://settings/fonts ). Then you can pick whatever font you want, and Wikipedia (and most other websites) should respect that. Whatamidoing (WMF) (talk) 06:36, 21 November 2018 (UTC)

Thank you Whatamidoing (WMF) for following up on this with me. I understand your reply and will adopt its counsel moving forward. In itself, that resolves my individual needs and concern. As it appears, there are no collective concerns to address; leaving this a mooted matter. That so, I am not averse to an archiving of this section if it ought be. I yield this to another's discretion; and remain. John Cline (talk) 17:04, 21 November 2018 (UTC)

Some remarks about the interface

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. Aschmidt (talk) 23:00, 15 December 2018 (UTC)

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. Aschmidt (talk) 10:39, 31 January 2019 (UTC)

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) (talk) 19:28, 15 April 2019 (UTC)

@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. Aschmidt (talk) 10:32, 22 April 2019 (UTC)

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. Whatamidoing (WMF) (talk) 22:29, 22 April 2019 (UTC)

> 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. Whatamidoing (WMF) (talk) 22:34, 22 April 2019 (UTC)

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. Aschmidt (talk) 12:15, 26 April 2019 (UTC)