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!
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.
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.
I was used to switching back and forth to use User:Ohconfucius/script/MOSNUM dates but unfortunately installing new wikitext mode gets rid of that script in source editing too.
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.
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. ~~~~
> 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) 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.
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.
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.
> 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?
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.
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.[1]
↑ 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.
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?
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.
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.
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...
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.
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) ~~~~
