Hello,
> 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?
That is about the worst and most harmful topos ever invented by the
Wikipedia community. I am sorry I reply this to you - I have heard
this line about a dozen times from others and now my frustration
became too big to not answer :(
Wikitext is not a proper IQ test - it is an "are you a geek like the
rest of us?" test. And it is not really good for that either.
I remember the first time I edited a MediaWiki page. Among other
languages I already mastered Latex and sed by that time. Latex wasn't
easy to learn but I knew how powerful it is when I finally get it. sed
was even worse in some respects but finally it saved me 100s of hours
of work during the years.
And so there were wikitext, with its quite funny and not so consistent
syntax just for producing simplified and uniform html pages. At this
time I could not feel the vast expression power of plain text+markup
in my hands. I think when people say stuff like " WYSIWYG is known to
be much less productive than WYTIWYG" they are actually referring to
stuff like latex or html source editing and they claim the same power
for wikitext, but that power is not there.
Having operated a lot of MediaWiki instances for years, having
attempted to implement an alternate editor at least 3 times (why I'm
on this list) and also doing research on the Wikipedia corpus I really
grown to respect the whole project and especially every editor who
carried out this huge achievement. But I still could not extend my
respect to wikitext.
> 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".
A classical freshmen commencement procedure: awkward things to do,
some humiliation, and bullies.
I understand that wikitext became an important part of this culture.
But I also think that the knowledge of wikitext should not be a status
symbol of our group membership unless we want to appear as a sect or
something like that.
> 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?
It is the same flawed argument again. We have a serious quality
management problem, inappropriate edits. You assume that it is best
solved by using a somewhat cryptic language which will tell us apart
the good from the bad. But I don't think we know what we are measuring
with our wikitext-test at all.
Ethical merits? Surely not.
Good or bad intentions? Surely not.
Knowledge about the article one wants to edit? Surely not.
Devotion to make an edit? Probably.
Markup skills? Probably.
Tolerance for outdated interfaces? I say this, too.
As a result:
1) We know for sure that despite the wikitext barrier we have lots of
false negatives, that is inappropriate edits or vandalism. That is
because we can only measure the devotion to edit wiki and not the
intentions or wisdom.
2) We have no clue how much the false positive is - knowledgeable
people with good intentions, who fail on markup skills or initial
devotion; the ones who go away when seeing wikitext. Or the ones who
inadvertedly mess up a page's markup the first time they edit and
getting reverted by an admin, etc.
Ah, well sorry for the harsh sentences,
peace
Mihály Héder
> 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 <[email protected]>:
>> Hi wikitext-l!
>>
>> I've read http://www.mediawiki.org/wiki/Future/Parser_plan recently, and the
>> plans seemed strange and scary to me.
>> In several places, there is the following stuff said:
>> ...rich text editor which will let most editors and commenters contribute
>> text without encountering source markup...
>> ...further reducing the need of advanced editors to work with markup
>> directly...
>> ...by integrating well with a rich text editor, we reduce the dependence of
>> editors and commenters on dealing with low-level wikitext...
>> ..."oh there's that funky apostrophe thing in this old-style page". Most
>> editors will never need to encounter it...
>>
>> Such plans seem very scary to me, as I think the PLAIN-TEXT is one of the
>> MOST IMPORTANT features of Wiki software! And you basically say you want to
>> move away from it and turn MediaWiki to another Word, having all problems of
>> "WYSIWYdnG" (...Is What Wou don't Get) editors. I don't think I need to
>> explain the advantages of plain-text markup to core developers of
>> MediaWiki... :)
>>
>> I've patched the parser code slightly (in mediawiki4intranet) and I
>> understand it's not perfect, so I support any effort for creating a new
>> parser, but if it involves moving away from markup in the future fully...
>>
>
>>
>> _______________________________________________
>> Wikitext-l mailing list
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/wikitext-l
>
> _______________________________________________
> Wikitext-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitext-l
_______________________________________________
Wikitext-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
