Re: [Wikitext-l] Odd plans on Future/Parser_plan - are they true?

Judging from other dev pages and maillist activity they seem to be striking true. I fully agree with the thread starter that the direction in which MediaWiki in general and Wikipedia in particular is going is controversial at best: it has started with a plain text markup and now it's going to end (and finish) with a "less-than-Word" solution. But I'm afraid we are not the ones who can influence this as the core devs seem to have already decided that the community needs WYSIWYG. But since it won't harm to add a few of my own arguments I'll do so just in case someone wants to give it a second chance. First of all, if editors can't master even the simplest wiki markup (without templates and the C/HTML mixture) than what good he's for as an editor? Basic Wikipedia markup contains a dozen of tokens, if not less. On the contrary, those who've mastered the basics have passed the first and unobtrusive"editorial filter". WYSIWYG editor is going to level everyone and give more chances for inappropriate edits. Come on, if someone has no free 5 minutes to learn the basics once and for all than why he must be allowed to edit pages in the first place? And you'll need to have more than 5 minutes to learn WP edit rules anyway - and no WYSIWYG will save you from this unless WYSIWYG is needed to boost the statistics of 'EPD'. WYSIWYG is known to be much less productive than "WYTIWYG" (what you think is what you get - plain text) when writing more or less long texts, is more robust (doesn't need any modern browser with contenteditable divs which in turn needs less CPU power, etc.), less error-prone (no chances to get markup that isn't visible - in plain text there are no invisible markup whatsoever; this includes semi-hidden markup like URLs which are hidden under link caption), over-9000 technical benefits (no need to reinvent/reimplement Unicode, can be edited even without a web browser in any text editor on any platform and any device, etc.). And I'm sure anyone can come up with a few more points. I have a hunch that all of this was already discussed long time ago before taking such a critical decision in changing 'wikitext' to 'wikiword' - and given amount of work done I doubt this can be changed now. However, --hope dies last--, I can't just keep silent all the time, especially if there seem to be people thinking my way too. A. Aharoni in his recent "reimplementation of editing functions in the Visual Editor" thread has outlined just a subset of technical difficulties and inconveniences for its first non-English users regarding rich text editing. Y. Tarasievich has just rightly said that current MediaWiki markup is HTML by another name. IMO this is the main problem: not inconvenient editing means but inconvenient markup syntax itself. I think the markup initially was planned for English articles. Moreover, it probably wasn't foreseen to have become so complex, with #directives and <extra markup>. This is perfectly understandable and no one is to be blamed. However, now may be the time to refactor old problems into new strengths. Making markup language-neutral is easy enough: even a single person can carry on the research to find keyboard symbols that are easily accessible across different language standards. From my experience they are ! % * ( ) - = _ and +. This will eliminate the need to layout switches (for example, currently a Russian Wikipedia editor must switch layout 5 times in typing simple "<u>underline</u>" since neither < nor > are present in Russian layout; the same goes for links: "[[link]]" and "[[link|caption]]" - pipe is also not present here). My study indicates that the number of available symbols will allow to avoid HTML-style tags completely - this will further simplify the markup. For instance, instead of <u> "__" can be used; <ref> can be replaced by "[[*ref]]" for uniformity with links; and so on. I am ready to give expanded explanation if anyone is interested. Special tokens like #REDIRECT, {{-}}, <imagemap>, __TOC__, etc. that all use different syntaxes can be uniformized in a way similar to template insertions: {{redir New page}}, {{clear}}, {{imagemap image.png, title x y, ...}}, {{TOC}} and so on. Templates can be called as {{tpl template arg arg arg}} - even if we keep { and } that require layout switch in some languages we eliminate the pipe which just makes things worse and text - less readable. To sum it up plain text editing might be an issue but not the main one. Mind you, Wikipedia has gained 10.5 mln articles with 347 mln edits with its current (not very convenient to be blunt) text editor. If that was a big issue Wikipedia wouldn't be what it is today. Old markup can still be entirely supported. I'm sure the team understands that building a visual editor on top of current markup is not the best way to 'fix' it as it will mean headaches for the developers. But it's not necessary: new parser system can incorporate both markups and use old compatibility layer to not only parse old markup into new document tree but even transparently convert it into new markup. Users won't even notice that something has changed after upgrading their MediaWiki - not until they try to edit a page and find that its markup has been seamlessly transformed. A top-notch WYSIWYG editor most certainly would not hurt, especially if it's built on top of good document tree. But in my opinion low-level markup is primary to the rich editor and is extremely easy to implement, at the same time maintaining maximum platform compatibility. Even a single person given enough motivation and a sane amount of time can build the entire system - parser/serializer/editor. This is hardly true for ambitious visual editor with integrated Unicode/multilanguage support that is currently underway by the Wikitext team. Signed, P. Tkachenko 2012/2/6 &lt;vitalif(a)yourcmc.ru&gt;ru>: