Please add translation tags to 2017 wikitext editor#See also sections. Better if Special:MyLanguage or any auto redirect type tag is added (sorry I forgot the terminology).
Talk:2017 wikitext editor
About this board
Hi, thanks for your interest in the 2017 wikitext editor. Please post all feedback at 2017 wikitext editor/Feedback, in any language. Thank you!
Mark for Translation #See Also
How to activate a text editor
How to activate a text editor that gives you edit html and texts in BOLD, Italic, etc?
It sounds like you're trying to install a third-party wiki. If you want the "2017 wikitext editor", then it is part of Extension:VisualEditor.
Impossibility to put redirection on some Namespace
Hi, I still don't understand why we can't put a redirection on some namespaces with the wikitext editor or the visual editor ? The problem exist since the creation of those editors, and it's very annoying for me to have to switch editor (I have to go to the Beta menu, desactivate the wikitext editor and reload the page, all times) when I need to put a redirection on a page on some namespaces, especially the Template or the Wikipedia namespaces.
Perhaps we can think that we're not usually put a redirection on this namespaces, but half my edit is merging page, so I pretty often have to put redirection on those namespaces.
The fault is in the browser.
In Internet Explorer IE 11.0.9600.18860 the syntaxhighlighting doenst work. Everytime i click an highlighted word the edit Windows scroll to the top. --~~~~
Extension:CodeMirror#Browser_support seems to say that yes, problems can still occur. I don't think I have found anything about this specific browser in Phabricator. Would you mind reporting either on the talk page for the extension, or Phabricator directly? Thanks.
Quotegrote, would you please follow the instructions at Help:Locating broken scripts#Test if you have problems related to user scripts or gadgets and tell us whether it's still broken in "safemode"?
Not anymore, my company has rolled out a new Version of IE. --~~~~
... do I install this mode? Is there a configuration parameter, a software dependency, etc. ... I am asking since I did not find the docu.
Publish changes dialogue is confusing
I really like the new editor but I quite confused about the 'publish changes' dialogue. The first thing I want to do after editing is to have a preview. I would like to have a preview button next to publish. The publish dialogue itself has a confusing layout. Two button on top with 'resume' and 'publish', the edit comment area in the centre and 'preview' and 'review' at the bottom. 'Resume' is nothing else than closing the dialog, normally called 'cancel'. This can also be achieved with an X on the right top like in a normal dialogue. The UXD team has to decide if the want button on top or on the button of the dialogue, splitting the up is strange. The first time I opened this dialogue I didn't find the preview button because there is the edit summary beneath the 'resume' and 'publish' buttons and I didn't expect more button below the summary. The same applies to the 'Review your changes dialogue'. I think publish without preview shouldn't be so easy because editing the source code is always error prone.
Yes this is a common complaint and tracked in https://phabricator.wikimedia.org/T44138
I think that the team agrees with you that this dialog needs some work. It was designed originally for the visual editor, where some things, especially the (non-)use of page previewing, are significantly different.
We can't use "Cancel" for the "Resume editing" button, because it makes people afraid that their changes will be lost (i.e., "Cancel the whole edit and discard all my work" rather than "Let me make one more change before I save my changes").
I don't think that any of the boxes in the visual editor have an (X) in the corner. The style documentation begins at OOUI. I believe that one of its sub-pages explains which buttons belong at the top (generally, the most commonly used ones) and which belong underneath.
Undo's don't work with the new editor
Sorry, did not mean to post here. Will post in the feedback section. Thanks.
New category pages
In the 2010 wikitext system, if you click on a category redlink, it gives you an empty category page to edit and at the same time displays what pages are currently in that category.
But in the 2017 wikitext system, if you click on a category redlink, all that appears is an edit box. Since categories don't show up on "what links here", there's no way to see what's in a category before you create a category page...! Can we have the category listing visible when we click on a category redlink?
I agrre with that feature. The workaround to see the categories is to delete some parts of the URL.
Update on community-consensus blocker issues?
An EnWiki RFC resulted in overwhelming consensus that there were at least two issues serious enough to block deployment of the New Wikitext Editor:
There has been no constructive update on Phabricator in months. It's particularly troubling that Jdforrester_(WMF) appears to have declared the second item as invalid (wontfix?), and he hasn't responded when asked how or whether it will be resolved.
Is the NWE project still planning to move forwards to deployment? And if so, how will the two blocker issues be resolved? Is it anticipated that NWE load times can and will be drastically reduced? Is there a plan for NWE to provide genuine previews?
A few points:
- According to the model that you were using, whether an issue actually blocks deployment is ultimately determined by the dev team (i.e., not by a vote or discussion among core community members).
- I don't think that there is anything more to be said about the load times right now. The team is not currently focused on that issue. It will doubtless be prioritized again in the future. At that point – but not between now and then – there will presumably be more activity on the Phab task(s).
- "Invalid" means that the request is wrongly formed, impossible, or irrelevant (e.g., reporting a bug against VisualEditor when the problem is a bad user script). "Declined" is "wontfix".
- On the "simulated previews" task, you were asked to clarify the nature of your request. Although you have replied in the task after that question was asked, I do not see an answer to that question. The question is essentially binary, so you need to choose one of the two options. It would be very helpful if you would please reply – your reply can be very brief, and need not say anything at all about communities, consensus, or process – to say whether the idea behind your request is more like,
- "Please improve preview, keeping in mind the work that is slowly but steadily removing the so-called 'genuine preview' from use", or more like
- "Please make the preview match the so-called 'genuine preview' now, knowing that in many cases, this will mean adding code to this preview in one month, only to delete that code the next month, when the 'genuine preview' stops supporting that particular bit of strange wikitext code or stops silently fixing up that bit of bad HTML".
I don't think that the team will be abe to make any relevant comments on that task until they are confident that they understand whether you are asking for improvements that will be valuable for years to come, or temporary changes that have some practical value today but will have to be reverted later.
According to the model that you were using, whether an issue actually blocks deployment is ultimately determined by the dev team
If you'd like to discuss the theory involved in that model, and what would happen after the dev team did that, I suggest we move that dark topic to a discussion non-specific to the NewEditor. I'd like to take a shot at aiming this discussion towards collaborative progress on this particular case.
On the "simulated previews" task, you were asked to clarify the nature of your request.
Please note that I terminated "my request" five months ago. That was the day I opened the RFC. At that point I considered my requests null and void. The community would either reject them, or modify them, or assert them itself.
The Community now owns the two Phab tasks. When the RFC closed I updated each task description with the verbatim RFC problem statement, the verbatim RFC proposals, and the close rendering each proposal as the voice of the community. The proposal-text states the nature of the task.
I am here as a random individual inquiring how the WMF intends to respond to the Community.
As a closely involved random community member, I am happy to offer any insight or advice or assistance in interpreting the community consensus, for successfully resolving the Phab tasks, or for assisting any potential ConsensusCanChange discussions between the WMF and Community.
I'll try to clear up some misunderstanding. You asked if this is improvements that will be valuable for years to come, or temporary changes that have some practical value today but will have to be reverted later. This is a permanent improvement.
You said: The question is essentially binary, so you need to choose one of the two options. The task is option 3 or option 4. If I may, I'll phrase your 'binary' options like this:
- Keep fake previews and play whack-a-mole fixing only some rendering errors.
- Keep fake previews and play whack-a-mole fixing only some rendering errors. By the way we'll be doing double-work whacking some moles twice, adding then removing some bits of code from the fake preview.
1&2 are fundamentally the same option. Your second option just shines an extra spotlight on why fake preview is a design error. If you're adding and removing preview code, the design is wrong. Preview-specific code should be relatively small and almost maintenance-free.
- Previews must use the article-view rendering engine. The preview button in the current wikitext editor tells the server 'show me this article'. It simply reuses the article rendering engine to show an actual preview of the article. The NewEditor preview button tells the server "show me what it would look like in VE". That's stupid. The task is for the NewEditor to do what the current editor does, ask for actual article renders. Quoting the RFC, This fixes the assorted rendering errors all at once, and it ensures that previews remain synchronized with article views when any changes are made to the software. Preview errors won't exist, work to update or fix previews won't exist, and any code changes to article views automatically apply to previews for free.
- We could happily retain our current wikitext editor. Note: Qgil offered this as an example of an appropriate actionable blocker when he was explaining the TCG. His exact phrase was Thank you, we are happy with the current status.
- Implicit: If the WMF feels that important evidence or arguments were not considered in forming the consensus, they could be raised in a new ConsensusCanChange discussion. That can alter or void the task.
I don't think that there is anything more to be said about the load times right now.
You missed the question I asked. I didn't ask about progress. I asked whether the WMF anticipates the task can and will be successfully resolved. If the issue was examined and the answer is 'yes', it would be helpful to post that answer. If the answer is "we have no idea" and the WMF is blindly driving the train forwards, that's a problem.
Do devs have a credible expectation that load times can be improved to be comparable to our current wikitext editor? Or is there just a vague hope that load times can be improved by useless few percent?
For the project overall, the options are:
- We happily keep the current editor.
- The NewEditor will successfully resolve both issues, with genuine previews and load times reasonably comparable to the current editor.
- Opening WMF-Community discussions to cooperatively form a plan.
- Boldly deploy against consensus and see how it goes. I suggest any dark details go in a separate discussion about non-collaborative cases in general.
I am hoping for any of 1,2,3.
Let me give you a practical example, and then you can give me your disinterested managerial advice about what you would recommend:
If the team had immediately implemented "the genuine preview", then one of the things they would have needed to do is to add code to Parsoid right after the RFC (March 2017) to change handling of some language conversion markup. This would have been necessary to make the so-called "simulated preview" match the old parser.
Then this month, in June 2017, they would have ripped that code out because that mess was just removed from the old parser.
Given these facts, would you have recommended that the team add code in March, even when they knew that it would have to be deleted three months later? Is that how you would have spent those limited resources?
Ok, we're not disagreeing about anything. We're talking about different things. Let's try this:
- The community wants the NewEditor code fixed.
- Jdforrester doesn't want to fix the NewEditor. He offered to spend increased developer resources on Parsoid code instead.
Look at the example you gave. You just described what Jdf proposed. I think Jdf's proposal is a bad plan. I think you also think it's a bad plan. It doesn't solve the problem either. It's an expensive way to make the problem smaller.
The task is to either keep the current editor, or change NewEditor code.
The current editor gives flawless previews. The NewEditor would also have flawless previews if it did previews the same way as the current editor
What does the current editor do? In simple terms, the preview button tells the server "pretend this is a saved article, show me what you send to readers".
What does the NewEditor do? It tells the server "send me something else". The NewEditor is actively requesting the wrong thing.
I understand that there are technical reasons why that can't be done. (I do not claim to understand what those technical reasons are.)
Also, that's essentially the same question, but on a slightly larger timescale. We could ask it this way:
- Previously approved plan: Remove the old parser from the old editors. Put Parsoid in the old editors. Then all the editors will match (because they'll all use Parsoid for everything).
- Proposal: Take Parsoid out of the new editors. Put the old parser in the new editors. In a few months, take the old parser back out of the editor, and put Parsoid back into the new editors. Then all the editors will match (because they'll all use Parsoid for everything).
Does that sound like a good use of resources?
Ping @Whatamidoing (WMF) for answers?
I still don't see an answer to my question for you. Without that information, it's really difficult to know what else to say.
I'm sorry if I left you confused by not directly answering your question. I tried to trim out unproductive distractions, trying to get the focus back to the issue that needs to be resolved. (1) Your questions keep trying to force-feed me a false choice, and (2) as you said you're not an expert on the technical issues. The question you posted was nonsensical. The parsers are on the server. That's fine, you're not expected to be a programmer. Trying to discuss technical implementation details here only derails the discussion. I asked who said it can't be done, and I asked whether they were rejecting a particular solution or whether they were saying it can't be fixed at all. However even that is an unhelpful distraction at this point.
The WMF built the NewEditor in secret, the entire architecture was wrong, and then the WMF failed to follow Agile development process. When alpha testing hangs big red signs on problems, you fix or rebuild the prototype. Abandoning a bad architecture and rebuilding the right architecture is cheaper, and you get a better outcome. Instead the WMF spent nine months digging the hole deeper and deeper.
The RFC result was that the community would "happily retain our current wikitext editor".
I'm not asking the WMF to spend one cent fixing the NewEditor. The community isn't asking the WMF to spend one cent fixing the NewEditor.
However in the spirit of the Technical Collaboration Guildeline, in the spirit of collaborative constructive procedure, the community didn't give a naked "no". The RFC result gave a crystal clear explanation of why the existing product was being rejected. That is exactly the feedback the WMF says the community should give. The WMF can understand exactly what the problem is. The WMF's technical experts can evaluate whether the problem can be fixed. If the issues can be fixed, the WMF can then evaluate whether it's worth investing resources trying to fix the problem or whether to drop the project.
My advice, for what it's worth, is that the WMF should not attempt improve the current design. The performance and preview problems are symptoms of the bad architecture. They are unreasonably difficult and unreasonably expensive to fix. Even if the editor is improved to a minimally deployable state, the long term result will be poor.
If the WMF insists on pouring money into trying to fix the NewEditor, that budget overrun is entirely due to the initial design errors.
For the last three and a half months I have been asking the MWF for a constructive response to the RFC. Hopefully for the last time: I am asking whether the WMF intends to (1) keep the current editor, (2) attempt to successfully resolve the blocker issues, (3) open a good faith dialog with the community, or (4) combat the community.
What exactly do you mean by "the current editor"? See Editor if you don't know their names.
I have told you repeatedly that there is no plan to prevent people from editing raw wikitext. For the foreseeable future, this will always be possible. Is this what you're really asking?
What exactly do you mean by "the current editor"?
Please don't play games.
The RFC reached consensus on two independent points:
- Block deployment of the 2017 editor due to performance. (Technically a consensus on load time, but we all know that will encompass preview times and performance in general.)
- Block deployment of the 2017 editor due to previews.
Unless the community is satisfied that both issues are resolved, that is a consensus to block deployment.
If the WMF is unwilling or unable to constructively deal with the situation, the next step is for the community to do so.
The next RFC proposal would be to ask whether we want to leave the 2017 Editor permanently stuck in beta features, or whether to terminate the nonviable beta feature. The community can easily and gracefully terminate the 2017 editor:
- First, try asking the WMF handle termination of the 2017 editor for us. If not:
- Optional: Institute an edit filter. Every edit with the 2017 tag would generate a notice that the 2017 Editor betatest is ending, and that the user should turn it off in their preferences. This could run for a week or two.
- At that point, we could set the edit filter to hard block 2017 editor edits.
- Renewed request for the WMF to remove the non functioning 2017 editor serverside, to eliminate any risk of anyone actually hitting the edit block.
There is no plan to remove the 2010 WikiEditor. You are therefore "retaining" that option, no matter what happens to the 2017 wikitext editor.
"Remove 2010 WikiEditor" and "Offer 2017 wikitext mode" are unrelated concepts. I don't see why you keep framing this as an either/or. Nobody is trying to take away what you've already got. Editors can have both editing enviroments listed in their prefs (along with a couple of others), and choose whichever one they want.
We block deployment of the 2017 editor, then:
The 2010 Wikitext Editor remains the default Wikitext editor.
And what about the preferred status in each project? Is it up to the community to decide which editor will be Beta, which default, or will this be imposed on the communities like the unwanted, buggy MV was introduced with pure and ruthless might?
Sorry, I don't trust the WMF enough already after the open war against the communities for the flimsy piece of bling the MV was, and they didn't even apologize for this completely inexcusable actions by those who imposed SuperPutsch e.a. OK, SuperPutsch is disabled for now, the main perpetrators have left, but not all. You should be a bit more explicit in your language on these sites that you will listen to the community decision for a change. Grüße vom Sänger ♫(Reden) 17:18, 31 July 2017 (UTC)
Speaking in very broad generalities, the WMF decides (e.g., based upon user testing) the best settings for readers and new editors, and the WMF respects the communities' views for the best settings for experienced editors (e.g., an admin dashboard).
There are some important principles that modify these rules. They include (but are not limited to):
- If a preference setting exists, then you personally get to decide how to set it, even if your choice is different from what most experienced editors in your community prefer.
- Nobody overrides Ops. If Ops says that a piece of code is bad for the servers, then that code gets removed, no matter who wrote it or where it is located.
So you still want to disregard the communities and decide as dictators what's good for the unwashed masses, did I get this right?
"The WMF respects the communities' views for the best settings for experienced editors" is the opposite of disregarding the communities.
Let's set aside "broad generalities".
Thanx in advance for your answer.
I have told you repeatedly that there is no plan to prevent people from editing raw wikitext. For the foreseeable future, this will always be possible. Is this what you're really asking?
Nope. Your comment is bizarre, and completely non responsive to what I wrote.
If there is no one at the WMF capable of understanding the situation, or constructively responding to it, then it appears the only option is for the community to kill the 2017 editor from our end.
You asked, in heavily formatted text above:
"I am asking whether the WMF intends to (1) keep the current editor".
I am answering the question you asked:
- To the extent that 'the current editor' refers specifically to the 2010 WikiEditor, and
- to the extent that we are talking about existing plans and reasonable beliefs about what might be planned during the next few years, then,
- yes, the WMF intends to keep the 2010 WikiEditor and not remove it.
NB that this statement does not constitute a promise that the 2010 WikiEditor will be maintained for the rest of our lives, or that all other wikitext editors will maintained, or that no additional editors will be added.
This statement also does not imply that whenever the 2010 WikiEditor is removed (because all software has a finite shelf life), that the replacement will be the 2017 wikitext mode, or indeed, that its successor will be anything that currently exists.
The statement is only that the 2010 WikiEditor, which you call "the current editor", will be kept, as one of several options available in editors' preferences, for an unknown length of time, which is believed to be best measured in years (as opposed to "months" or "decades").
Is the future of Extension:WikiEditor now reasonably clear to you?
The question was how the WMF plans to resolve the issue. The issue is that the community reached consensus on deployment blockers.
(1) NOT deploy 2017 editor as default, and keep the current editor as the default.
If that is what you are saying, then yes the answer is clear. If that is not what you are saying, then no, the WMF still has not given any constructive response to resolve the issue.
There seems to be some ongoing confusion about "blockers". According to the the model you explicitly invoked when you started that RFC, the community can't declare anything to be a blocker. Only product managers can do that.
I have a favorite joke about American baseball. You may have heard it before. It runs like this:
Three umpires are talking about the difficulties of judging whether the pitcher threw the baseball fairly.
The first umpire says, "Some are strikes, and some are balls, and I call them as they are."
The second umpire thinks that it sounds a little arrogant, so he says, "Some are strikes, and some are balls, and I call them as I see them."
The third umpire thinks for a moment, and says, "Some are strikes, and some are balls – but they ain't nothing until I call them!"
Some community concerns are blockers, and some are not – but they ain't nothing until the product manager calls them.
But the WMF is not an umpire, it's just a service agency acting for and on behalf of the community, the ultimate highest entity in the wikiverse. Same goes for the devs: They are there for the communities, not the other way around.
Especially if something should work solely for the editing community, the editing community has the last word, not the service employees who just work for their benefit of the communities.
I do not agree that the Wikimedia Foundation is "just a service agency acting for and on behalf of the community", or that "the community" (however you define that) is "the ultimate highest entity in the wikiverse", or that the devs do not constitute their own, separate community. It may also interest you to know that, as a matter of US law, the Wikimedia Foundation is an educational charity and not a service agency.
My point, though, is that Alsee said that he wanted to follow the model on a particular advice page. Alsee's chosen advice page directly and explicitly says that only the product manager can decide whether a problem is "a blocker". Alsee should therefore stop saying that the community has made a decision that Alsee's chosen model reserves to only the product manager.
There are just two current editors, the normal one and VE, and now this new beta test inside VE. There are some add-on gadgets to improve several aspects of the normal editor, like WikEd or such, but that's it. I don't care about how the inner nerd call them, it's not that tough to get the meaning of it. If you intend to listen to others at all, that is, some feature not very popular with the devs @WMF in the years of early VE, MV, Superputsch, FLOW, Gather or other rubbish. Grüße vom Sänger ♫(Reden) 16:58, 28 July 2017 (UTC)
> There are just two current editors
This is not true.
If it were true, then nobody could object to the upcoming Removal of the 2006 wikitext editor, because all of them would already be using "the normal one".
But these different wikitext editors do exist, and some people do use them.
I understand that there are technical reasons why that can't be done.
Could you please identify who said it "can't be done"? And clarify whether they they were objecting to a particular implementation or saying they can't provide acceptable previews in general?
I have been nothing but impressed with our developer's ability to do whatever the WMF wants to do. Our devs eat hard problems for breakfast, and achieve 'almost impossible' when necessary.
Setting aside any technical details of how the problem could be solved: If you're telling me "there are technical reasons" why we can't so something as basic as proper previews, either (A) we need to re-hire the people who built our current editor, or (B) the person in charge doesn't want to fix it.
For our purposes there is no important difference between 'we can't do it for technical reasons' and the boss saying 'I don't wanna do it'. You appear to be telling me it won't be done. In that case I will just copy-paste:
- We happily keep the current editor.
The NewEditor will successfully resolve both issues, with genuine previews and load times reasonably comparable to the current editor.
- Opening WMF-Community discussions to cooperatively form a plan.
- Boldly deploy against consensus and see how it goes.
The formal RFC result was a package proposal of "#1 or #2". Informally, my impression is that the community actually wants #1. The community was willing to buy into my package proposal "#1 or #2". The design is fundamentally wrong and the community knows it. To avoid a wall of text, I'll cut my retrospective of the process-problems which resulted in sinking massive resources into a bad design. Option #2, applying bandaids & deploying a bad design, would be an actively detrimental use of additional resources. I only included #2 because a #4 conflict would be incredibly destructive. #2 was a desperate attempt to find some sliver of collaboration from the WMF.
If you're going to strike #2, is the WMF intending #1 abandon the project? #3 good faith discussions acknowledging that fixing the project and abandoning the project are on the table? Or #4 battle? Please please please give an answer, which isn't #4.
By the way, I have a new fatal breakage report for you. The NewEditor button labeled "preview" dies with an HTTP 413 error for some pages. I'm not sure how widespread the problem is, but here's a test case which demonstrates the error.
When I tested the button-labeled-preview on the United States article the result wasn't much better. It took 30-35 seconds to generate the fake preview. This rather coincidentally matches the time it takes to click edit-in-VE for the article. It appears the fake preview button basically works by doing a full load of VE and removing the various buttons from the screen. The button is useless. I don't care if edit-in-VE is going to show me dancing rabbits in tophats, and more significantly I could simply click edit-in-VE and it would be just as fast (i.e. just as slow). The fake preview button is a worthless duplicate of the edit-in-VE button. Dump the useless fake-preview button, and dump the entire broken NewEditor design.
You offering a false choice. You get to keep "the current" editor AND you will get the ability to choose another option, if you want to use it. It's not 1 "or" 2 "or" 3 "or" 4; it's the older wikitext editors AND the new one, in consultation with experienced editors AND in consideration of other users.
Problems with the new editor
Things I dislike about the new editor:
- Previews aren't on the same page.
- Edit summaries are no longer cacheable by the browser, meaning I always have to retype them.
@Sweyn78 Out of curiosity, why do you want the edit preview on the same page? I haven't seen any mention of changing this. As for the edit summaries, I feel your pain. @Whatamidoing (WMF), are you aware of any plans to fix text in the edit summary box no longer being stored in the browser's cache?
Some preview gripes regarding 2017 editor are captured in https://phabricator.wikimedia.org/T153306
I like being able to Ctrl+F and scroll up and down without having to wait for the page to reload every time I want to look at the article. I want to generate previews only when I want to generate previews, not every time I want to look at the page. Editing huge articles on a slow computer is a pain because of this.
You can preview by switching to visualediting too.
Sweyn78, do you have Special:Preferences#mw-prefsection-editing set to "Show preview on first edit" at your home wiki?
Whatamidoing: I didn't. Setting it did not help with the new editor, however, and the problems I described still afflict me.
Wargo: True, but I really prefer to edit only in source mode; and using this workaround still doesn't give me both the source and a preview at the same time.
I'm trying to figure out how, in any of the "old" wikitext editors, you can look at the article without clicking the preview button (which causes the page to reload, although that might not be so obvious).
No, I *want* to click the preview button. :p
What I want is for the resulting preview to be on the same page as the source editor box. The new editor, in its current state, cannot show both simultaneously, and always reloads the preview when it is viewed. When the preview is on the same page, I can look at the previous rendering if I so choose (like if, say, I fix a typo in the header on a huge article -- I wouldn't want to have to reload the preview just because of that).
Alternatively: having a button for showing a preview and a second button (in preview view) for reloading the preview. This would allow people to look at the previously generated preview for an article without having to reload it every time.
That's been a very popular request. I've linked to it at the top of the thread.