Page MenuHomePhabricator

New Wikitext Editor: Previews should use the article-view rendering engine
Open, LowPublic8 Story Points

Description

There are a large number of errors where the New Wikitext Editor preview does not match the genuine article view after save. Discussions on projects pages indicate that some of those rendering errors are explicitly CANTFIX/WONTFIX, that the WMF plans is to play whack-a-mole on endless individual rendering errors, and that the WMF is explicitly aiming for less than 100% accuracy due to CANTFIX/WONTFIX issues. These issues appear to be due to using the VE engine (Parsiod etc.) to generate previews, rather than using the genuine article view engine (PHP parser etc.).

The task is for previews to use the genuine article view engine (using PHP Parser etc.), like the current wikitext editor, fixing all of these errors at once.

Strong community consensus that this issue is serious enough to be a deployment blocker: EnWiki Village Pump RFC is here. The key text was:
Actionable Blocker: Article previews. Previews are a critical part of the learning process for new editors, as well as a critical tool for experienced editors. Inaccurate previews will confuse, disrupt, and frustrate. Possible resolutions:

  • We could happily retain our current wikitext editor; or
  • previews must use the article-view rendering engine (this is called the PHP parser), as well as any other relevant parts of the article-view software stack. 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.

Related Objects

StatusAssignedTask
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedEsanders
OpenNone
OpenNone
ResolvedJules78120
OpenNone
ResolvedDannyH
OpenNone
OpenEsanders
OpenNone
OpenEsanders
OpenNone
DuplicateNone
ResolvedJdforrester-WMF

Event Timeline

Alsee created this task.Jan 7 2017, 11:48 AM
Pppery awarded a token.Jan 7 2017, 4:38 PM
Alsee added a comment.Jan 8 2017, 3:16 AM

To avoid a split discussion, see my Technical Collaboration Guideline comment at T154843#2926550.

Legoktm added a subscriber: Legoktm.Jan 8 2017, 4:09 AM

Based on discussions on project pages this task appears to be a WONTFIX

Could you provide links for context?

Alsee added a comment.EditedJan 8 2017, 5:12 PM

The issue was first raised by me 14 weeks ago half way down this thread on Talk:Wikimedia_Product. That was before any project page or documentation even existed yet. "Whatamidoing, can you please please please go to the head of the New Wikitext Editor project and tell them that a new "Wikitext editor" that doesn't have genuine wikitext support is a deal breaker? It has the same Parasoid-based fake wikitext that Flow has. I suspect there would be a consensus against even having it in Beta-features until that "bug" is fixed. I've already saved a screenshot showing the New Editor botching the preview in nine different ways at once, and it's not hard to show lots more. A new wikitext editor that can't give accurate previews is a non-starter."

Four weeks later, after a project page was created, Rogol Domedonfors opened this thread on Talk:2017_wikitext_editor.

When the page 2017_wikitext_editor/Feedback was created over three weeks ago, I opened this thread. In that post I explicitly stated that the issue should be categorized as an actionable blocker. I should have explicitly referenced the Technical Collaboration Guideline.

To be clear, I only posted a small fraction of the rendering issues that I happen to know of. The list of rendering issues that I've found are certainly a negligible fraction of the rendering issues that exist. Some are common issues, some are weird corner cases, but the proposal here is to sync previews with genuine article views to fixing everything at once. It also ensures that previews stay synchronized when any patch alters any aspect of page renders. Running previews through an entirely different rendering engine was a baffling design choice.

Legoktm renamed this task from New Wikitext Editor: Provide genuine article previews to New Wikitext Editor: previews should match article view (use PHP parser).Jan 8 2017, 8:32 PM
Restricted Application added a project: VisualEditor. · View Herald TranscriptJan 17 2017, 1:16 PM
This comment was removed by Whatamidoing-WMF.
Jdforrester-WMF renamed this task from New Wikitext Editor: previews should match article view (use PHP parser) to New Wikitext Editor: Ensure that previews match article view as much as practical.
Jdforrester-WMF lowered the priority of this task from Normal to Low.
Jdforrester-WMF removed the point value for this task.
Alsee renamed this task from New Wikitext Editor: Ensure that previews match article view as much as practical to New Wikitext Editor: Previews use the article-view rendering engine. (Consensus this is a blocker issue).Mar 21 2017, 5:46 PM
Alsee raised the priority of this task from Low to High.
Alsee updated the task description. (Show Details)

I updated the task description to reflect the closure of the RFC on this issue. Also, my understanding is that blocker tasks inherit the priority of the parent task.

Alsee, unless you are personally planning to do a task yourself (e.g., submit code, create design, write documentation, etc.), then you should not be setting its priority field. See https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities

Jdforrester-WMF lowered the priority of this task from High to Low.Mar 21 2017, 6:07 PM

I've corrected the task to inherit from the one it talks about, and re-set the priority. I'm minded to revert the changes made from an accepted task that we would do (make the differences negligible) to one that's invalid (switch over to the legacy system that's being replaced), but I might have missed some nuance. @Alsee, can you clarify?

Jdforrester-WMF set the point value for this task to 8.Mar 25 2017, 1:53 AM

can you clarify?

The RFC question, closing result, and every response, are available here. If the RFC itself, and the RFC text copied into the task here, aren't sufficiently clear, then I'll need a more specific question of what you want clarified. Over 90% of editors supported one or both issues as deployment-blockers, and almost as many people supported each issue individually. Almost everyone considers the New Editor to be an unacceptable downgrade unless (at least) these issues are sufficiently addressed. I hope you consider that to be a striking and seriously concerning result.

We have all known for years that the number one factor for projects running into problems is lack of early community input. A project to replace our editor absolutely should have had significant community consultation during concept and design phase, so we could all collaborate on what we want and need in a New Editor.

I will try to list every possible path I can imagine ahead. I welcome you to cite any alternative I overlook, and hopefully indicate which one(s) you have in mind.

  1. Engage the community in discussion, trying to generate WMF-community consensus on a mutually acceptable plan.
  2. Deploy only to wikis that want it.
  3. Implement the same kind of previews as the current editor has, per RFC and task description.
  4. Keep the current wikitext editor as default, per RFC and task description.
  5. Push project out as default, against overwhelming community objection that it's a downgrade.
  6. Avoid the issue until deployment is scheduled, and deal with 1,2,3,4 or 5 in panic mode.

I've corrected the task to inherit from the one it talks about, and re-set the priority. I'm minded to revert the changes made from an accepted task that we would do (make the differences negligible) to one that's invalid (switch over to the legacy system that's being replaced), but I might have missed some nuance. @Alsee, can you clarify?

It doesn't explicitly say use the legacy PHP parser, it just says to use whatever is generating the actual views readers see. At least for NWE, I'm not sure what the technical blockers are to using the API's action=parse with some kind of editstash stuff. If/when the default parser changes, that API module will get updated for it anyways.

Whatamidoing-WMF renamed this task from New Wikitext Editor: Previews use the article-view rendering engine. (Consensus this is a blocker issue) to New Wikitext Editor: Previews use the article-view rendering engine.Mar 30 2017, 6:23 PM
Alsee added a comment.Mar 4 2018, 7:42 PM

I'm copying related concerns submitted at 2017 wikitext editor/Feedback:

  • Accidental misspelling of a category's name is not seen in the preview.
  • List of used templates won't get updated.
  • The effect of {{lowercase title}} or other title-changing code cannot be previewed.
  • Category changes resulting from addition of new templates do not appear in the preview. For example, try inserting a {{Use British English}} template in English Wikipedia.
Pppery renamed this task from New Wikitext Editor: Previews use the article-view rendering engine to New Wikitext Editor: Previews should use the article-view rendering engine.Oct 16 2018, 11:40 AM