On 02/06/2012 11:03 AM, Pavel Tkachenko wrote:
2012/2/6 Trevor Parscal tparscal@wikimedia.org:
I hope this effectively illustrates an alternative perspective on this subject. This is a very hard problem, and any course of action will involve some level of risk. We are trying our best to manage this risk, mostly by conducting a great deal of research and development.
This is understandable, the scale of problem is as such that it is inappropriate to take any action in one instant. I cannot say that your arguments have given me much to think about due to lack of specifics but I'm glad if they're more elaborated on the core level.
Still, I cannot see why it's impossible to first create a solid foundation without drastically changing everything and then build visual editor and other high-level structures on top of it.
The parser we are working on [1] should eventually give us the solid foundation you are lobbying for. It is strongly motivated by, but not technically tied to the visual editor. The enriched HTML DOM we are building (and actually most token stream processing including template expansion) is not tied to any specific syntax or user interface.
We do currently add some round-trip information to support a very gradual normalization of WikiText formatting without non-localized dirty diffs. Anybody wishing to experiment with an alternate markup UI could however ignore this issue initially, which should simplify the task a lot. Alternate markup-based user interfaces would require a different serializer and tokenizer, but can share the remaining parser pipeline, so this simplified task should indeed be quite manageable.
But in any case, we first have to implement a solid tokenizer for the current syntax and recreate at least a part of the higher-level functionality (template expansion etc) based on a syntax-independent representation.
Gabriel
[1]: https://www.mediawiki.org/wiki/Future/Parser_development