2017 wikitext editor/Feedback/2020

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

Cannot preview correctly

Tracked in Phabricator
Task T151911

When I used this editor to preview a table with nested userboxes in cells, it was all fine. However after I submitted, I was surprised to see the table was a mess. I know that userboxes may conflict to table because they also can be seen kind of tables, and I fixed the mess successfully by solving the conflict. But it is still weird that this editor cannot display this conflict. My browser is FF 71 on windows 10, and my skin is Vector. チルノ (talk) 15:46, 1 January 2020 (UTC)

Previews are a known issue. The preview was deliberately designed to work differently than previews in the normal editor. Almost three years ago there was an overwhelming consensus at English Wikipedia to block deployment of the 2017editor, for design flaws including-but-not-limited-to previews and performance.

It's long overdue to remove the 2017editor from the betatest feature list. Alsee (talk) 06:28, 2 January 2020 (UTC)

Editor Visual

Estou impedido de usar o Editor Visual Asmcds1995 (talk) 18:45, 18 February 2020 (UTC)

Is it working now? (It's okay to reply in Portuguese. MediaWiki.org is a multilingual wiki.) Whatamidoing (WMF) (talk) 20:17, 28 February 2020 (UTC)

Bug

Pour information : https://phabricator.wikimedia.org/T246164 -- Nemo ^Discuter 17:35, 2 March 2020 (UTC)

Has this been deployed as default? Plus, signature bug

Apparently this is now the only option? I can't get it to go away. I wouldn't mind if it didn't have bugs. For example, when starting a new section on a talk page and trying to use the signature button (four tilde button), it puts the signature in the subject line box, no matter how many times I move the cursor to the text box.(see screenshot: https://imgur.com/g39n9JX) ~ Kaliforniyka (talk) 07:29, 9 March 2020 (UTC)

That's the 2010 wikitext editor. It looks like you have installed several user scripts, too. I've left a link for you to test at https://en.wikipedia.org/wiki/Wikipedia:Teahouse#Visual_editing_not_available._Only_2017_wikitext_editor_available. Whatamidoing (WMF) (talk) 15:37, 9 March 2020 (UTC)

systemLanguage (multilingual svg) not supported in preview

https://phabricator.wikimedia.org/T208620

T247671

If i use a image such as [[File:COVID-19_Health_care_limit.svg|mini|lang=de|description]] it shows the image in the default language (e.g. english) not in German (de). As soon as I save the page it is in German. Since I create multilingual svgs, I would like to check them before using in articles.

This image is used here:

https://de.wikipedia.org/w/index.php?title=COVID-19&direction=prev&oldid=197763810#Vorbeugung JoKalliauer (talk) 17:48, 14 March 2020 (UTC)

Visual Editor doesn't support Template editing

使用者代理： Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0 奧田95 (talk) 12:48, 15 March 2020 (UTC)

Yes, you're right. The visual editing mode can't do rich text editing, so editing most templates would be an exercise in frustration. Perhaps someday... Whatamidoing (WMF) (talk) 01:25, 24 March 2020 (UTC)

Wikipedia how to add main and auxiliary directories, how to add Wikipedia internal links

Wikipedia how to add main and auxiliary directories, how to add Wikipedia internal links Wlchunxiaodi (talk) 17:41, 16 March 2020 (UTC)

Hello, what you mean by main / axuiliary? For internal links, use [[Link Page]]. Thanks Camouflaged Mirage (talk) 13:09, 31 March 2020 (UTC)

Help:VisualEditor/User guide may answer your questions. Whatamidoing (WMF) (talk) 01:12, 18 April 2020 (UTC)

No longer can use date formatting script

I was used to switching back and forth to use User:Ohconfucius/script/MOSNUM dates [1] but unfortunately installing new wikitext mode gets rid of that script in source editing too. Valereee (talk) 12:59, 29 March 2020 (UTC)

The 2017 editor is incompatible with all previous scripts. User:Ohconfucius or someone else would have to rewrite the code to get it to work in the 2017 editor. However there is little chance that will ever happen. Almost exactly three years ago I ran an RFC at EnWiki Village Pump. Community consensus was to block it from being deployed as a replacement for the current wikitext editor. The Foundation has stalled this project in beta for three years, but it appears the manager on this project imagines he's going to steamroll forwards deployment at some point. I would not advise holding your breath. Alsee (talk) 15:30, 29 March 2020 (UTC)

Thank you, I'd wondered why it had been in beta so long. I was testing out the beta to see how I liked it, and I did like many things about it. I use visual editor and source editing both and do end up switching back and forth for various reasons often. ~ Valereee (talk) 16:09, 29 March 2020 (UTC)

Valereee, VisualEditor/Gadgets (and specific examples, such as VisualEditor/Gadgets/Creating a custom command and VisualEditor/Gadgets/Add a tool) has information about changing scripts to work in VisualEditor, if @Ohconfucius or anyone else wants to look at it. At the English Wikipedia, within the CS1 citation templates, you can also use the |df= parameter to achieve the same effect. Whatamidoing (WMF) (talk) 17:38, 30 March 2020 (UTC)

> being deployed as a replacement for the current wikitext editor

To the best of my knowledge, nobody in the WMF has ever proposed replacing the 2010 wikitext editor with the 2017 wikitext editor. I hope that nobody has been spreading that false rumor?

In late 2018, the then-product manager and I planned to move the 2017 wikitext editor out of Beta Features (i.e., the tickbox for turning it on/off moves into regular "Editing" preferences tab, with no changes to anyone's personal settings), but then he decided to change companies, and the team has been busy with other projects since then. If you all think the location of the prefs tickbox is really important, then I can ask to have the tickbox moved from the Beta Features prefs tab to the regular Editing prefs tab. I don't think it's all that important myself, though. Whatamidoing (WMF) (talk) 17:39, 30 March 2020 (UTC)

@Whatamidoing (WMF) you saynobody in the WMF has ever proposed replacing the 2010 wikitext editor with the 2017 wikitext editor but the Project page for the 2017Editor says we'll begin to provide it by default in place of the current wikitext editor.

I don't know if you saw it but here is what the the project manager posted to the mailing list: our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform' for all kinds of editing... there are currently six pieces of editor software beyond the visual editor... Our goal is to gradually reduce the number of pieces of software with equivalents based on the single platform... experimenting with providing a more modern wikitext editor

The goal is to reduce the number of editors. The manager then built an additional wikitext editor. (The opposite of reducing.) That means the plan was either to build-and-immediately-scrap the 2017Editor (obviously not), or the plan was to scrap the current wikitext editor as redundant to the new editor. So please don't claim there was no plan to kill the current wikitext editor. At best, there was a plan to exterminate the current editor and no one informed you.

Some of your comments suggest there might be a miscommunication or misunderstanding. For example you talk about the location of the preference setting - I see that as irrelevant. I don't care where the preference is. Put it anywhere you want. You also try to reassure me that the Foundation won't change the preferences of existing users - again I see that as irrelevant. Go ahead and change the prefs for existing users - I don't care (much). It just will annoy us and most of us will simply change it back. Promising you'll keep the current editor for the next hundred years doesn't much matter either. Maybe the issue will be more clear if I narrow it down to the essential part:

(Not) deploying the 2017Editor as default for new users.

I have no idea if it is intentional, but you're trying to advance or the Foundation's agenda to make 2017Editor the default for new users by hiding it in the things-you-don't say. It's not working. The issue is the default. And apparently I need to explain that "default" is what is given to a blank-slate new user.

The Foundation kept Flow as a walking-corpse for six years. For six years, all fixes and upgrades on the project were wasted acts of necrophilia. I had to organize consensus across three wikis to get the Foundation to acknowledge that the project failed. Three years ago I delivered the Foundation the EnWiki consensus on the 2017Editor. The 2017Editor has been kept as a walking-corpse for three years. Any upgrades or bug-fixing on this project are wasted acts of necrophilia. Apparently the only way I can help the Foundation is to again organize consensus across multiple wikis until the Foundation buries this corpse. Alsee (talk) 09:18, 1 April 2020 (UTC)

On the difference between hopes and plans:

This seems to be my week for people quoting half a sentence to prove a point. That sentence begins "Only once we've met our quality requirements (including new-user testing and experienced-user happiness)...". That hasn't happened (because the team switched projects). Therefore there has never actually been a proposal to make that change.

The Foundation does not actually have a plan, a proposal, a goal, or an agenda to deploy the 2017WTE as default for new users, or anyone else.

Have some staff previously written about their hopes to do so? Yes. Is anyone actually going to do it? I make no promises about the next decade, much less then next century, but I can tell you that nobody at the WMF right now is even talking about doing this. The only deployment plan ever actually written and proposed for the 2017WTE was to not turn it on by default for anyone – and that plan was never implemented.

Whatamidoing (WMF) (talk) 17:50, 6 April 2020 (UTC)

First I'd like to note something a staff member said that really stuck with me. They said something to the effect of "The worst case scenario is when a project blows up on deployment day". At the opposite end the best and cheapest time to identify problems is in the initial concept&design stage, before anything is built. Between those endpoints there's a steady sliding scale of "earlier is always better". For brevity, I will say the Foundation has Institutional patterns that tend to railroad itself into the worst case scenario. I acknowledge efforts to improve, but they have been uneven with limited success. I will switch back to the main topic, and reintegrate this side-comment in a minute.

The manager who built 2017Editor stated our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform' for all kinds of editing... there are currently six pieces of editor software beyond the visual editor... Our goal is to gradually reduce the number of pieces of software with equivalents based on the single platform. I will emphasize "Our goal" and that the the goal was to reduce the number of editors. The product page was also clearly written with an expectation that "quality requirements" will be met at some point, it estimates "probably in mid-2017", and it explicitly states an intent to "provide it by default in place of the current wikitext editor" when the anticipated conditions are met. I don't have a link handy, but I recall the manager was so dead-set on steamrolling the project out that he declared it some sort of binding strategy "Contract" superseding all consensus. In fact that manager made it clear that the Parser Unification project was his roadmap for deploying the 2017Editor. If Parser Extermination Unification is deployed, that will break previews in the current editor and "fix" previews in the 2017Editor. However that would actually be purely disruptive. It doesn't end the consensus-block against deployment of the 2017Editor, so deploying Parser Extermination Unification would just sabotage the current editor. Hmmm.... I wonder if there would be consensus against Parser Extermination Unification?

The Foundation has earned a reputation for doublespeak and weaslewords and dishonesty when staff are pursuing an unpopular agenda. I doubt I was the only person who had a rather unfavorable view when you attacked me about "plans" in the 2017Editor RFC. There was clearly a sizable group of staff dedicating substantial resources with a well-organized intention for eventual full deployment. I don't think many people cared much about how you defined "plans", I don't think many people cared that no specific deployment date had been set.

Whether is was deliberate or whether it was poor project management, the 2017Editor project was effectively built in secret. Building a new editor should have been a big deal. There was no project page for it, and as far as I'm aware there was little or no prior advertisement. When I stumbled across a stray reference to it, I was told that no information would be available until the initial version was essentially complete. Returning to my earlier comments, the worst possible time for the community to weigh in on the project is when there is a concrete deployment plan. The best time for the community to review and comment would have been in the concept&planning stage. The Foundation's inclination to say the 2017Editor RFC shouldn't have been run at that time was part of the Foundation's institutional pattern of railroading itself into the worst case scenario. The editors in that RFC were clearly not swayed by your argument that there was "no plan". The fact that it had been BUILT was evidence enough that it was well past time for the community to give the Foundation clear feedback on the product. Earlier would have been better, later would have been worse.

If nobody in the Foundation has any plans to deploy the 2017Editor as default, then the Foundation should terminate the product and yank it from beta completely. As the manager who built it well argued, we shouldn't have [eight] different interfaces by which to confuse users, [eight] different sets of bugs to track down, and [eight] different places where features can interact in unexpected ways and which need to be tested. If the 2017Editor isn't going to replace the current Wikitext editor, it is a wasteful drain of resources to maintain a redundant editor.

On the other hand if there are such plans (or goals or hopes or daydreams or whatever you want to call them), then that crashes head-on into existing consensus against the product. I am certain that the EnWiki consensus will be echoed at enough other wikis to constitute an effective Global community consensus. And again we have the conclusion that it is a wasteful drain of resources to maintain a redundant editor that can't be deployed.

The only rationales for maintaining the 2017Editor are either an unrealistic fantasy that consensus will change, or a pathological fantasy of hostile deployment by force. Alsee (talk) 00:29, 7 April 2020 (UTC)

> If Parser Extermination Unification is deployed, that will break previews in the current editor and "fix" previews in the 2017Editor.

Why do you believe that having one parser provide all previews in all editors (and also be the same parser that creates the HTML displayed on all devices) will break previews in the 2010 wikitext editor? Whatamidoing (WMF) (talk) 15:58, 7 April 2020 (UTC)

@Whatamidoing (WMF) do you have any link about changing the 2010Editor to use Parsoid? Alsee (talk) 18:25, 7 April 2020 (UTC)

That is the main point of the parser unification project. All parsing work, including all previews and processing all pages after they're written to the database, will be done by the same parser. See, e.g., the second paragraph of Parsing/Parser Unification: "The goal of this project is to arrive at a single parser that supports all clients and use cases." The word "all" in that sentence includes the preview button in the 2010 wikitext editor. Whatamidoing (WMF) (talk) 17:59, 9 April 2020 (UTC)

On the status of the 2017WTE:

I do not agree that the 2017WTE is a failed project. It's been used for 7 million edits so far (1.8 million edits at the English Wikipedia). More than a million articles have been created in it. Along with many other experienced editors, I use it preferentially (mostly because of the built-in link search, although others like its citation and template tools).

The 2017WTE is VisualEditor's built-in wikitext mode. Maintenance for the 2017WTE is maintenance for VisualEditor. VisualEditor is in maintenance mode (=the same status as most of the editors that the WMF supports), rather than active development. That means that no major new features are planned, but bugs are being fixed.

They did release a new table-editing feature last month, to fulfill an emergency request from English Wikipedia editors working on the pandemic-relate articles. It allows editors to sum columns in tables. This, however, was unplanned work.

Whatamidoing (WMF) (talk) 18:12, 6 April 2020 (UTC)

On the 2017WTE for new editors:

I'm curious why you object to new editors having the 2017WTE automatically.

Just in case this wasn't already clear, whatever wikitext you (mis)type into the 2017WTE, that's exactly what gets saved, exactly what gets shown in the diff, and exactly what the next person to edit the page has to work with. Parsoid never touches it, so there is no possibility of any round-tripping errors, no automatic correction of Special:LintErrors, no whitespace changing, etc.

I don't remember why you are concerned about which toolbar is at the top of a new editor's screen, given that all of the wikitext toolbars available to new editors produce the same end result: the wikitext that's on their screen is the wikitext that gets saved. Is it just the small (and temporary) differences in the previews, or was there more to it than that? Whatamidoing (WMF) (talk) 18:24, 6 April 2020 (UTC)

I could list direct practical reasons, primarily the longer load time. (We especially don't want new users staring at a loading-bar and deciding to abort.) But it's deeper than that.

One of the topics I plan to open on the new Village Pump page will the Foundation's general VE strategy over the last decade. It will be long and I'll have to pull together a lot of supporting links. I'm not going to do that here. The very short version is that I intent to try to lay out a case that the Foundation has been pursuing a strategy that is well-intentioned, but harmful. The 2017Editor is both a symptom and a part of that strategy.

There was a joke from the manager who built the 2017Editor. I have a link saved somewhere, but not handy. There was discussion was about the low adoption rates of VE. He said (approximately) there were two ways to get more people into VE. Either the Foundation could make VE better, or the Foundation could make wikitext worse.

To again quote that manager, our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform'. He wasn't trying to build a better wikitext editor. He was pursuing an agenda, an agenda to rebuild the wiki around VE "as the core platform". He didn't care that building the 2017Editor inside VE would result in harmful load times. That harm was an utterly irrelevant and acceptable trade-off. The Foundation isn't deliberately making wikitext worse, nonetheless the Foundation's VE strategy is resulting in a systematic series of tradeoffs sabotaging our primary editing environment.

If one buys into the theory that VE is bringing a glorious future with hordes of new users, then the strategy makes sense. If that theory is wrong, then the Foundation is systematically killing the goose that lays the golden eggs. Alsee (talk) 18:23, 7 April 2020 (UTC)

Are you referring to m:IRC office hours/Office hours 2014-06-19? * Pppery * _{it has begun} 20:10, 10 April 2020 (UTC)

Yep, that's the joke I had in mind. Alsee (talk) 09:41, 14 April 2020 (UTC)

BUG

my english is poor ，so i have a video to display the bug. [https://drive.google.com/file/d/1inY0RyeUgfYtFjIaQaCq-t3U2rR1GEZl/view?usp=sharing] my brower is google chrome 版本 80.0.3987.163（正式版本） （64 位）.dell pc is windows 10 home 1903 18362.720 . wiki is vertor，&safemode=1 is useless....important : can you speak chinese？ Air7538 (talk) 02:24, 6 April 2020 (UTC)

Hello,

That looks like it is caused by a badly-customised system message on the Chinese Wikipedia. You should ask the community there on 维基百科:互助客栈/技术.

----[抱歉，這是自動翻譯的。]

你好，

看來這是由於中文Wikipedia上的自定義系統消息錯誤導致的。 您應該向维基百科:互助客栈/技术詢問那裡的社區 Jdforrester (WMF) (talk) 17:04, 6 April 2020 (UTC)

Kindly add these Wikicode buttons

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.

---

The newer editors lack these buttons

https://commons.wikimedia.org/wiki/File:Wikitext_mode_code-insertion_buttons.png

Even on some pages especially on Wikipedia these buttons are not appearing even if I turn off beta features.

The code insertion buttons (those were available at the bottom of edit field) were greatly helpful. But obsolation of those buttons have made Wikitext-mode editing more confusing and difficult. Kindly bring back those code-insertion buttons.

(I dont know if that old feature has a specific name. If you know its name then please feel free to add that technical term). RIT RAJARSHI (talk) 05:45, 6 April 2020 (UTC)

That's the CharInsert extension. Those were legacy buttons that were meant to be replaced by the 2010 Wikitext Editor. They were left around for a "short" period for people to adjust from the (now removed) 2006 Wikitext Editor (which had no extensible system for special characters), and were not meant to be used. Sadly they've stayed around, but should not be used in general. Communities who want special characters should add them in the site configuration, like the German Wikipedia has done. Jdforrester (WMF) (talk) 16:59, 6 April 2020 (UTC)

@Jdforrester (WMF): Status: Resolved. It has been discussed in Teahouse and IRC chat. https://en.wikipedia.org/wiki/Wikipedia:Teahouse#How_to_get_these_code_insertion_buttons_in_en.wikipedia.org?

Thank you for your support.

Regards.

RIT RAJARSHI (talk) 17:04, 6 April 2020 (UTC)

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

Cannot see the list of Pages (i.e. templates) transcluded onto a page (i.e. article)

When I am editing with source code (pre-2017 wikitext) editor (editing and clicking onto preview button), I can see the message:

Pages transcluded onto the current version of this page (help):

And a list of the templates used in the page I am editing (in the article).

But, when using source code (2017 wikitext) editor, I cannot see nor the message, nor the template under it.

This is very important to go to the templates, a see how to use them when editing an article, for example, and other uses.

On the other hand, Mediawiki.org says I are not logged and appears a button (Add topic anonymously), when I really am (I can see my Username in my Userpage. Finally, I could do it, relogin in Mediawiki.org. BoldLuis (talk) 11:19, 26 April 2020 (UTC)

Go to the three-bars menu (☰, near the big blue button) and choose "Templates used" from the menu.

When MediaWiki is confused about whether you're logged in, then the solution is often to log out (deliberately) and log back in. Whatamidoing (WMF) (talk) 02:33, 1 June 2020 (UTC)

а где авто-викификатор? может он где-то и спрятан - не нашел

Браузер: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36

URL-адрес: https://ru.wikipedia.org/w/index.php?action=edit&preload=Template%3AArticle+wizard%2Fskeletonperson&editintro=%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F%3A%D0%9C%D0%B0%D1%81%D1%82%D0%B5%D1%80+%D1%81%D1%82%D0%B0%D1%82%D0%B5%D0%B9%2F%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D0%B8&title=%D0%9A%D0%B8%D0%BC_%D0%A2%D1%85%D1%8E%D0%B8&create=%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D1%82%D1%8C+%D1%81%D1%82%D0%B0%D1%82%D1%8C%D1%8E Sagivrash (talk) 14:34, 11 May 2020 (UTC)

If you open ru:Ким Тхюи and then click "Create source" ("Создать код"), you will see Wikificator in the hamburger menu. By the link, you won't see it, partly because the URL has "action=edit", not "veaction=editsource", partly because Wikificator doesn't have time to load before VisualEditor does. Jack who built the house (talk) 15:34, 11 May 2020 (UTC)

Tx. I know how to find it in classical source-edit mode, but I cant`t find it in beta-mode. 37.145.227.167 (talk) 17:51, 11 May 2020 (UTC)

You've got the answer about 2017 Editor.

IKhitron (talk) 17:53, 11 May 2020 (UTC)

Right. Jack who built the house (talk) 18:21, 11 May 2020 (UTC)

ctrl-select

Will it be possible to select multiple text through the ctrl button (I'm using Windows) in the near future? Piranha249 (talk) 13:21, 23 May 2020 (UTC)

Do you mean that you read a sentence – "One two three four five" – and you want to select "One four five", skipping over the middle?

I have not heard them talking about this, so I don't think it will happen in the near future. Whatamidoing (WMF) (talk) 02:30, 1 June 2020 (UTC)

Disabling keyboard shortcuts

Hi all. I regularly use Ctrl+number to change tabs but the 2017 wikitext editor (and VE, for that matter) steals those shortcuts for something else. Is there a way to disable those shortcuts in 2017WTE? Taavi (talk!) 05:15, 18 June 2020 (UTC)

Maybe. See w:en:Wikipedia:Keyboard shortcuts#User scripts that modify keyboard shortcuts for some scripts that change some keyboard shortcuts. I doubt that any of the existing ones do exactly what you want, but you might be able to find someone at w:en:WP:VPT who could modify one to do what want. Whatamidoing (WMF) (talk) 00:34, 8 August 2020 (UTC)

Insert citation not working?

Yesterday, I noticed the insert citation function stopped working. It generates the cite from a URL without a problem as normal, but when I click "insert", an empty dialogue box appears, then quickly disappears, and the cite is not inserted. This happens on Chrome and Edge browsers, I haven't tried any others. Inserting a citation in VE mode still works without a problem. Sorry if this is the wrong place to report and thanks for looking into it. Levivich (talk) 19:03, 18 June 2020 (UTC)

I'm having the same problem. Also with inserting templates. Using Firefox and chrome in visual and source editing modes. Pelirojopajaro (talk) 07:39, 19 June 2020 (UTC)

I'm also having the same problems for several days. Also with inserting templates. Using Edge(Chromium ) in visual and source editing modes. (I often edit Wikipedia.) リトルスター (talk) 00:23, 20 June 2020 (UTC)

Same problem which has existed for about 4 days. Sudden change and nuisance not to have this feature. Have reset my preferences to default, then selectively checked and tried different settings in my sandbox, with no resolution of the problem. Bug? ~ Zefr (talk) 18:20, 20 June 2020 (UTC)

Same problem here ! On Chrome. Asterix757 (talk) 13:15, 21 June 2020 (UTC)

Same problem on Hebrew Wikipedia, using Chrome and Edge. Tamir Kalman (talk) 10:22, 22 June 2020 (UTC)

As of today, it's working normally for me again, on Chrome. Levivich (talk) 17:11, 23 June 2020 (UTC)

Me too on Japanese Wikipedia Edge(Chromium) :D リトルスター (talk) 23:11, 23 June 2020 (UTC)

Working today again. Thanks Asterix757 (talk) 23:15, 23 June 2020 (UTC)

Working for me again too on Hebrew Wikipedia. Thanks. Tamir Kalman (talk) 07:10, 24 June 2020 (UTC)

Discarding "recovered" changes

Agent d'usuari: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36

I want to discard changes that I had locally in the editor and were never published. I expected to do it closing the browser window, but these were "recovered" after reloading the page. There is a message saying that the changes were recovered, but I don't see an option in the user interface to discard them.

I even tried to log-out. The changes are always there. Seems a very obvious UX issue to me. Pere Orga (talk) 09:03, 20 June 2020 (UTC)

FWIW, the page is https://ca.wikipedia.org/w/index.php?title=Ajuda:Recursos_en_l%C3%ADnia Pere Orga (talk) 09:04, 20 June 2020 (UTC)

I believe that if you click the "Read" tab at the top of the page, it will discard your changes. I know it can be difficult to find a method that works for this. Whatamidoing (WMF) (talk) 00:41, 20 September 2020 (UTC)

Maybe the message that tells that the changes were recovered could include a link (to the "Read" tab?) to discard the changes Pere Orga (talk) 10:34, 24 September 2020 (UTC)

Problems for Teahouse Hosts and Admins on en-wiki

Yesterday, I was prompted by an Editing News update sent out by @Whatamidoing (WMF) to try out this editor. I'd not done so before, but soon had to disable it.

The first problem related to template alerts continually blocking much of the editing page. I'm pretty active at the Teahouse on English Wikipedia.there, where we have a template to steer users how to ask questions. Having to be manually dismiss this every time soon became very annoying.

The second problem might only be encountered by admins, but it's impossible to go to a previously deleted page and to click the links on the top left of the page to 'View or restore deleted edits' or the 'abuse log' link. Both links are visible, but are greyed out and non-functional.

I realise both issues are not going to be regarded by most users, but I'm afraid I regard them sufficient annoying that I would not want to try using the editor again unless I knew there's a way to avoid them recurring. Nick Moyes (talk) 13:33, 4 July 2020 (UTC)

The first one bugs me at WT:MED. Click [Edit source], hit Escape to get rid of the edit notice, click back in the box (because the Escape button makes it lose focus), and now I can finally type something. One of the things that I like about the Talk pages project/replying project is that the quick Reply tool ignores those edit notices.

The second doesn't sound familiar. I'm not an admin, so I can't reproduce it. Could you please check it again in safemode, and ping me with a note about whether that makes any difference? Whatamidoing (WMF) (talk) 21:44, 6 July 2020 (UTC)

OK, so since posting, I've discovered that I didn't need to manually dismiss the template notice by clicking the 'x', and that a simple mouseclick anywhere else on the page cleared the notice - so that is far less of a troublesome issue than I had first thought. I'm OK to let that one go, and it seems to function in the same way in desktop view on a mobile

The admin issue is still present in safe mode. And the 'view or restore deleted edits' link is greyed out when using both Chrome and Firefox with the default Vector skin. It might be worth me noting that, as the page loads (e.g. https://en.wikipedia.org/w/index.php?title=The_Broken_Drum_(pub)&action=edit&redlink=1&safemode=1) I initially see the two links coloured their normal, dark hyperlink blue for a fraction of a second, and then they grey out as loading finishes. If you feel it would be helpful to get further feedback, I could ask at en:WP:AN for other admins to check it out.

Oh, and another thing I've just noticed: I am unable to preview a page I'm about to edit (using my normal keystrokes of Alt-Shift-P) unless I have already made some kind of edit to that page. I regularly click 'edit source' and then immediately Preview the page before I start making any edits just to check how the page appears prior to me working on it. Having to add a space and then delete that space in order to activate page preview is quite unhelpful in my opinion. Can we get rid of that requirement? Nick Moyes (talk) 22:32, 6 July 2020 (UTC)

I can also reproduce the issue with viewing deleted edits on the beta cluster and can confirm it is annoying. WAID: If you want I can give you admin rights there, just let me know what your username is there. Taavi (talk!) 13:33, 7 July 2020 (UTC)

Also as a workaround I can use "Edit notices" dropdown to view deleted edits but it's an extra click, link to abuse log isn't there and it is confusing to have non-clickable text that looks clickable. Taavi (talk!) 13:36, 7 July 2020 (UTC)

@Whatamidoing (WMF) As well as the issue added to my post above, I've found another thing, and this one's REALLY BIG for me, and I was unsure whether to start a new thread about it. I suspect others have already commented on it, though I haven't checked.

I've now been using this editor for a couple of days solid, today I was editing, tweaking and testing various welcome message templates in my sandbox. I found it SO irritating that I can't see the wikitext and the previewed content on the same page at once. Why not?

I can now no longer simply move the slider up and down to see the effect of my edits - which previously gave me the previewed text set directly above the wikimarkup text. My 'workflow' - as you WMF folk like to say - is made much more circuitous than in normal source editor mode. I now have to preview to see the potential changes, then (if I don't like them) I have to click left to go back to the previous screen, and I then have to actively cancel the 'Summary' screen (this one doesn't disappear with a mouse click) before I can see and edit the source code again. In source editor, I simply moved the right-side slider up and down to see the differences. I think this is going to be far more of a game changer for me than all the other comments above, and will force me to abandon the 2017 wikitext editor. But I will keep on trying and see what else I find, because I do think the mixture or source edit and visual editor potentially very interesting, and well-worth exploring further.   Nick Moyes (talk) 22:25, 7 July 2020 (UTC)

Nick, this is not an uncommon complaint. Do you mostly need to check/re-check in articles, or when replying to a comment? Whatamidoing (WMF) (talk) 17:56, 8 July 2020 (UTC)

That's a great question that got me really thinking hard about how I work. Whilst I use page preview all the time (for articles, replies & template tweaking), I think it's actually when replying/interacting with other users that Preview Changes needs to be quick and slick. It's easy to mistype and thus cause miscommunication, so a hasty preview before publishing is invaluable. Despite that, I still rush at times, and then spot my error later - sometimes much later, or not at all.

So, typing Alt-Shift-P prior to tying Alt-Shift-S is a speedy way to check layout and content. Oh, the times I've missed a colon off, and my reply would have continued on the previous line, or I'd missed off my signature had I not Previewed Changes and spotted my sloppiness. Page Preview in source editor that is already one extra step that far too many people omit, and thus create accidental errors, so anything that makes us all more reluctant to check our edits is obviously a retrograde step.

Yesterday, I was tweaking templates and experimenting with simple coding in my sandbox with the new 2017 editor in VE(https://en.wikipedia.org/wiki/User:Nick_Moyes/sandbox2). Not being able to quickly compare by modified code with my work's appearance on the same page was pretty frustrating, to be frank (especially as I'm not very good at it). You can view my edit history, but I can assure you that for every one 'save' I must have made 5 to 10 Previews, with all the clicking left that this entailed. But tweaking templates is a minor thing, whereas being able to easily make clear, properly laid out replies to other editors is essential to the project. So it's replies where I think my concern would mostly lie. Nick Moyes (talk) 20:27, 8 July 2020 (UTC)

Increasing the font size

I like this editor very much. But there is something that prevents me from switching to it. The font size is too small for me. For the usual editor I can increase it with something like this #wpTextbox1 { font-size: 15px; } (in my common.css). It doesn't work for 2017 Wikitext Editor. I tried with .ve-ce-branchNode selector but something overwrites that code. Is there any way to increase the font size? Ashot (talk) 21:47, 2 August 2020 (UTC)

When I open pages at hy.wikipedia.org in multiple editors, the fonts are all the same size. Is it different for you? Whatamidoing (WMF) (talk) 18:11, 18 September 2020 (UTC)

It is the same but the default size is too small for me. I know how to increase the font size of "regular" editor (like this) but this does not work for 2017 Wikitext Editor. Ashot (talk) 18:33, 18 September 2020 (UTC)

It must have a different CSS class name or something. I know very little about CSS, but I wonder whether it might use the same font as when you're reading. This is just a guess, but maybe if you search for mw-body-content in MediaWiki:Vector.css, then you will be able to find what you need. Whatamidoing (WMF) (talk) 01:04, 20 September 2020 (UTC)

Vraiment pas pratique

Agent utilisateur : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

URL : https://fr.wikipedia.org/wiki/Liste_de_sanctuaires_mariaux_en_France?veaction=editsource&section=18#C Ce nouvel éditeur n'est pas du tout intuitif, je préférait nettement l'ancien beaucoup plus simple. Technob105 (talk) 12:49, 15 August 2020 (UTC)

Agreed, it’s viscous on slow hardware. MBq (talk) 05:34, 1 February 2021 (UTC)

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

---

Hi, I tried this new feature, and now I want to turn it off. I unchecked the box in my account settings, saved, but it still works. What can I do? ~ Klima (talk) 11:57, 4 September 2020 (UTC)

If you (re-)uncheck the box, yet the 2017WE is still active, you can try pressing the "Purge" button (if the gadget enabled), click the real-time clock on the upper-right corner (if the gadget enabled), or type either ?action=purge or &action=purge at the end of the URL address.

I bet the refreshing issue must have interfered with the changes. George Ho (talk) 00:39, 10 September 2020 (UTC)

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

Best editor

Hi, I like this editor so much. Usually I edit in the VisualEditor, but this is better. I can edit the source and have the edittools like the visualeditor. Dr. Otztafan Kolibril (talk) 13:40, 11 September 2020 (UTC)

I'm glad that you like it. I use it a lot myself. Whatamidoing (WMF) (talk) 18:08, 18 September 2020 (UTC)

android and windows

is not optimal speed in chrome android & windows 10 old low end devices Baratiiman (talk) 11:44, 28 September 2020 (UTC)

farsi or english Baratiiman (talk) 11:44, 28 September 2020 (UTC)

specific with microsoft editor enabled Baratiiman (talk) 11:46, 28 September 2020 (UTC)

Do you find that the speed is better if you edit in safemode?

You can also ask for help at https://fa.wikipedia.org/wiki/ویکی%E2%80%8Cپدیا:قهوه%E2%80%8Cخانه/فنی Whatamidoing (WMF) (talk) 00:12, 14 October 2020 (UTC)

Cannot cut or paste large sections of text

Tracked in Phabricator
Task T264260

• Web browser: Both Safari and Chrome;
• Operating system: macOS 10.15.6;
• Wiki skin: Vector.

When I tried to cut or paste large sections of text, text residue and dislocations appear in the editing interface, and the editor cannot detect the changes I've made.

File:A bug with 2017 wikitext editor 202010.png is the screenshot when I tried to cut down all the text in the article, and the "publish" button in the upper right corner is unable to click.

This bug doesn't happen when I tried to cut or paste just a few words, but it is very annoying. Tim Wu (talk) 04:14, 1 October 2020 (UTC)

Thanks for filing this in Phabricator. Whatamidoing (WMF) (talk) 18:00, 12 October 2020 (UTC)

Demasiado lento

Tracked in Phabricator
Task T153306

Pone demasiados pasos intermedios para la realización de tareas comunes, con lentos diálogos emergentes para hacer cosas como insertar imágenes y plantillas, además de que botones que antes estaban a la mano ahora quedan ocultos, como el de insertar imágenes. Tampoco es claro: no resulta intuitivo que la previsualización es obligatoria, lo que hace que uno se quede buscando el botón. La ventaja del editor de código es su agilidad y este diseño implica todo lo contrario. Ivanics (talk) 19:07, 1 October 2020 (UTC)

Es la previsualización obligatoria? No lo uso normalmente. Whatamidoing (WMF) (talk) 00:13, 14 October 2020 (UTC)

Tienes razón: la primera vez que lo usé, la previsualización se activó obligatoriamente. Ahora me aparece como opcional en el cuadro de diálogo que aparece. Pero sigo creyendo que debería haber un botón para previsualizar y otro para guardar directamente en esta interfaz. Ivanics (talk) 17:25, 20 October 2020 (UTC)

Problems with 2017 wikitext editor compatibility in mobile devices when I change to desktop mode from the mobile view

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, in mobile devices, when I change to desktop mode in a browser, at the time of editing with the 2017 wikitext editor, it shows a notice that says: You are using a browser that is unofficially compatible with this editor. Could you solve this problem? Thanks.

Web browser: Google Chrome Operating system: Android Wiki skin: Vector Rodney Araujo (talk) 18:57, 5 October 2020 (UTC)

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

Hope add a fuction that I can change the font size of the code

The size of the code is not so large that it's hard to read and have problem with insert. I hope I can change the font size Qmacaw (talk) 02:13, 18 October 2020 (UTC)

@Xiplus, can you help this zhwiki editor? Whatamidoing (WMF) (talk) 20:26, 20 October 2020 (UTC)

Others answered

here

. Xiplus (talk) 23:41, 20 October 2020 (UTC)

[Feature request] Add parser profiling data (and one hotkey)

Tracked in Phabricator
Task T157625

Tracked in Phabricator
Task T267048

I switched to this beta version of the wikitext editor because using keyboard shortcuts to add code cuts down on a lot of editing time. I have two requests, however:

• Parser profiling data: I sometimes check articles for PEIS limits (e.g., COVID-19 articles using a lot of templates) to make sure that everything is being transcluded properly. I have to disable this feature and return to the standard source editor to find how many bytes have been used for PEIS below the editing window past the "Templates used in this preview" section. Can this be somehow integrated into the beta so that I don't have to switch back and forth?
• A formatting button and hotkey for nowiki tags. There's one for code tags already; I think it would be useful to add this feature not for articlespace, but for places like talk pages. Tenryuu (talk) 15:49, 1 November 2020 (UTC)

Your second request could be partially mitigated by copying https://meta.wikimedia.org/w/index.php?title=User:Whatamidoing_(WMF)/global.js&diff=20414463&oldid=20377059, which @Matma Rex might have generously written so that I'd quit whingeing about phab:T157625. Hotkeys are a problem, because there are approximately two hotkeys left unassigned.

I haven't found a Phabricator ticket for the PEIS limits issue. Whatamidoing (WMF) (talk) 05:08, 2 November 2020 (UTC)

Thanks for your reply and help, @Whatamidoing (WMF). That script works for me, even if it doesn't have a hotkey (no more constantly typing out <nowiki> tags is all I really ask for).

If there isn't a Phabricator ticket for parser profiling data, I'll start one tomorrow. Tenryuu (talk) 06:10, 2 November 2020 (UTC)

For anyone interested, I started a ticket for the parser profiling data at phab:T267048. Tenryuu (talk) 18:06, 2 November 2020 (UTC)

lags on large 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.

---

it really lags hard after a couple thousand bytes Betseg (talk) 16:54, 2 November 2020 (UTC)

Which wiki are you working on? Do you see this when you open the page, or at other times? And do you have Extension:CodeMirror (colored text highlighting) turned on? Whatamidoing (WMF) (talk) 17:41, 4 November 2020 (UTC)

that was on English Wikipedia, it lags only after i change something. text highlighting starts lagging with less bytes, but non-highlighted pages lag with moderately large pages too. Betseg (talk) 15:36, 5 November 2020 (UTC)

What's your web browser and operating system? Whatamidoing (WMF) (talk) 19:17, 5 November 2020 (UTC)

firefox, linux Betseg (talk) 23:14, 5 November 2020 (UTC)

which Firefox version, and which Linux distro? George Ho (talk) 01:15, 12 November 2020 (UTC)

82, arch Betseg (talk) 10:39, 12 November 2020 (UTC)

have you followed system requirements for your Linux: https://www.mozilla.org/en-US/firefox/82.0.3/system-requirements/ George Ho (talk) 11:08, 12 November 2020 (UTC)

yes Betseg (talk) 12:22, 12 November 2020 (UTC)

Issues with loading a large page while using the newer (2017) WTE have been known for quite some time [phab:T154843 and phab:T184857 (the latter that is stalled for now)]. I believe the issues would be likely not resolved anytime soon. George Ho (talk) 22:38, 12 November 2020 (UTC)

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

Be able to alternate between editors

I really do love the 2017 wikitext editor, I really do, but a lot of my scripts only work on the default one, and it is quite frustrating having to constantly go to the beta panel and switch it on and off. Is there a quicker way to switch editors than this? Isochrone (talk) 15:49, 22 November 2020 (UTC)

When I need to invoke one of the older wikitext editors, I hand-edit the URL to say &action=submit instead of &action=edit or &veaction=edit. This is not exactly convenient, but it is 100% reliable and quicker than changing preferences. Whatamidoing (WMF) (talk) 02:36, 24 November 2020 (UTC)

@Chlod wrote a neat bookmarklet that does this automatically, for anyone that needs it:

javascript:void function(){javascript:(()=>{if("en.wikipedia.org"==window.location.hostname){const a=new URLSearchParams(window.location.search);a.has("action")%3F"edit"==a.get("action")%26%26a.set("action","submit"):a.set("action","submit"),window.location.search=a.toString()}})()}();

Isochrone (talk) 17:39, 24 November 2020 (UTC)

@Berrely, the script has a few issues from minification (namely, it won't run due to a syntax error in the first section), so use this instead:

javascript:(()=>{if(window.location.hostname!="en.wikipedia.org")return;const params = new URLSearchParams(window.location.search);if(params.get("action")==="submit")params.set("action","edit");else params.set("action","submit");window.location.search=params.toString();})(); Chlod (talk) 17:47, 24 November 2020 (UTC)

How do I make the script work for both English Wikipedia and Wikimedia Commons? I'm not that experienced in JavaScript. Thanks! Pandakekok9 (talk) 06:34, 14 January 2021 (UTC)

Here's an approach that will make it work on all MediaWiki wikis.

javascript:(()=>{if(mw == null)return;const params = new URLSearchParams(window.location.search);if(params.get("action")==="submit")params.set("action","edit");else params.set("action","submit");window.location.search=params.toString();})(); Chlod (talk) 08:44, 14 January 2021 (UTC)

@Pandakekok9: you can use this modified version:

javascript:mw!=null?void((params=new URLSearchParams(window.location.search)).get("action")==="submit"?params.set("action","edit"):params.set("action","submit"),window.location.search=params.toString()):void 0)

Sportzpikachu (talk) 09:30, 14 January 2021 (UTC)

@Sportzpikachu What's the difference between yours and @Chlod's? Pandakekok9 (talk) 09:46, 14 January 2021 (UTC)

Sportz's version is much more compact, and is executed with just a single JavaScript statement. There's no difference other than the 31-character gap. Chlod (talk) 09:49, 14 January 2021 (UTC)

@Sportzpikachu's version for some reason doesn't work on Pale Moon 28.17.0. It's attempting to contact "intake-logging.wikimedia.org" when I try to use it. Pandakekok9 (talk) 11:18, 14 January 2021 (UTC)

Show preview button show not be placed inside the Publish changes modal

Currently the default (old) editor allows us to click the Show preview button without having to click Publish changes button.

I feel that the Show preview button show be move from inside the Publish changes modal to next to the Publish changes button. Similar to how it's currently layout on the default (old) editor. This should be reduce the extra click require to gain access to the function.

Furthermore, in terms of spaces, there are more than enough spaces to accomodate the Show preview button plus 1 additional button. Paper9oll 08:56, 3 December 2020 (UTC)

Thanks, this is T153306. ESanders (WMF) (talk) 23:49, 1 January 2021 (UTC)

'Show preview' function

My only complaint about the 2017 wikitext editor is that the 'Show preview' function takes up the whole height and width of my monitor screen; I don't need the preview to be that large.

Is it possible to have the 2017 wikitext editor's 'Show preview' function/preview page be exactly similar to the default/non-visual/non-2017 wikitext editor one?

Other than that, the 2017 wikitext editor is pretty great! Some1 (talk) 00:08, 29 December 2020 (UTC)

Thanks, this is T155732. ESanders (WMF) (talk) 23:50, 1 January 2021 (UTC)