Topic on 2017 wikitext editor/Feedback

When I tested the new editor some time ago, it gave badly inaccurate previews because it did not use the same parser as the genuine article view. I have reported this elsewhere, along with a screenshot of the new editor resulting in multiple corruptions of the article preview.

It appears the goal is for the new editor to eventually become the default wikitext editor. I believe the community will consider corrupt previews to be an unacceptable degradation of the current editing experience, both for new editors and experienced editors.

This should be categorized as an "actionable blocker". The new editor must use the same parser as the genuine article view before it is considered suitable for anything other than fringe opt-in usage.

Where was this "reported elsewhere"? Got any link and good steps to reproduce / a screenshot? Thanks in advance!

I included the screenshot here.

1. Redlinks don't render as red.
2. Black links don't render as black.
3. The third link is completely broken.
4. External links don't render as external.
5. The red styled text is completely broken, with the preview dumping fragmented raw wikitext onto the preview screen. (Holy crap!)
6. The new editor can literally display entire lines in the wrong order. (Holy crap!)
7. The new editor can randomly split one line into two. (The example uses hieroglyphs, but the issue isn't limited to hieroglyphs.)
8. Math display is broken, but that might just be an issue with the test server configuration?
9. Ref 1 doesn't show up in the references section, Ref 2 is misrendered as 1.
10. . . . There are countless other issues not shown here. For example there are multiple issues can also screw up section headings. I'm sure the Parsoid team can give you a pile of other examples. They have a project that scans hundreds of thousands of wikipages finding cases of "semantic errors" or "dirty diffs", most of which are cases which will also misrender.

I can't put the screenshot's wikitext into a Flow post. Flow literally can't save it. However I did post the wikitext on Phabricator. You can find it here. (When the Flow prototype was being built, the lead designer (Jorm) blew off countless editors who repeatedly told him that proper wikitext support was mandatory for any wiki discussion system. Flow's god-awful fake wikitext support is one of the reasons Flow has been rejected by the community. The Flow extension has been completely uninstalled from EnWiki.)

The issue with the new editor and the with Flow are directly related. They both use Parsoid rather than the genuine article-view PHP parser. Flow's problems are much worse because Flow runs wikitext through a round-trip through Parsoid. When you preview and re-edit, or save and re-edit, Flow throws away the wikitext and generates new, different, potentially broken wikitext. The new editor only does a one-way trip through Parsoid. That means the new editor saves wikitext correctly, it "merely" gets the preview wrong.

The fundamental issue is that the new editor uses a different parser than the genuine article view. That's a really bad design. Running around trying to squash bugs that I've listed above isn't a fix. That list is incomplete. Any divergence between the PHP parser and Parsoid is going to result in corrupt previews. The purpose of a preview is to see the the page the same way as when it's saved. That means using the same parser as the article view. That is the simple, obvious, and necessary solution.

The community accepts that there are all sorts of problems with Visual Editor (largely relating to Parsoid). VE is a secondary editor. Most editors don't use it. If someone chooses to work in visual mode then they are accepting the flaws and limitations that come along with visual mode. However the community is will seriously object if the WMF tries to replace the wikitext editor with an inferior editor. I believe the WMF will do a good job getting other stuff right with the new editor, but I'm concerned that load time and previews may be issues with the fundamental design. The community may consider it malicious it if the WMF tries to shove VE down our throats, trying to take away a perfectly good wikitext editor and trying to force us into an inferior "wikitext mode" in VE.

I had a similar issue. In userspace, previews of wikilinks go to subpages of userspace, not article space like they should do, and as they correctly do when the page is saved. i.e. when editing my sandbox [[Link test]] went to User:Samwalton9/Link test in preview but Link test when saved.

@Samwalton9 Filed as https://phabricator.wikimedia.org/T153277

This is now fixed in production; thanks for the spot!

1. preview surface not being enriched with VE's linkannotation magic.
2. preview surface not being enriched with VE's linkannotation magic.
3. parsoid, also a problem in VE.
4. this is an issue with the preview window not having the context classes that the styling requires (mw-body), as well as the preview surface not being enriched with VE's linkannotation magic it seems.
5. parsoid, same as VE. Not likely to be fixed if I remember correctly. This is an issue that basically awaits the further unification of the parser modes.
6. This is a Tidy effect. With the planned switched of the traditional parser to use HTML5 cleanup rules, this will also be the order the traditional parser will show at some point.
7. this seems fixed in production
8. this seems fixed in production
9. this seems fixed in production

Looks like a lot fewer issues than I expected based on the list.

Colouring redlinks basically requires an extra API call. Probably not too difficult.

Parsoid are working on the long tail of rendering issues, but in most real-world cases it is >99% accurate.