Hello, I cannot speak for the MW parser dev team, but I don't think your suggestion is operable. There is no shortage in well-designed, even wikitext like languages, that one could just pick and build a good editor for. Also, I'm sure we could come up with an even better one after a rational, collaborative work you suggest.
But then there are millions of pages already written in legacy wikitext and those must be editable with the new editor. So right now instead the rational approach, an empirical one should be taken - they have to rather ''find'' than invent a good enough model for those old articles, and also store everything in the old format. Not an enviable task, I feel I have to keep my fingers crossed for them all the time. Best Mihály On 8 February 2012 16:06, Oren Bochman <[email protected]> wrote: > I'm all for a modern WYSIWYG editor however it would still require an > underlying syntax. > > I disagree that that xhtml is a geek only storage format or that the current > Wikisyntax has a lower learning curve. > Hacking templates to overcome parser bugs is one of the worst experiences > I've has as an editor. > > I think that an xml subset is the ideal should be the underlying format. It's > the best known technology, has mature development tools. > It could be parsed to and written to most efficiently by browser, and even > the editor could be simplified by using it. > > A well designed format, would be easily transformed to and from other > formats. (xslt == toOthers, domParser = from others. This could provide > interoperability with other wikis format and a friendlier variant of the > existing wiki markup. > > A well designed format should be: > easy to parse (read : unambiguous, won't require context or semantics to > parse) > would be possible to auto complete > would permit gracefully error recovery without bothering the editor unless > required. > Would specify syntax errors and advise on corrections > Would be fully learnable in a couple of hours... > > If we put our heads together and come up with something like that we will > make some real progress. I think a time out is need because > the future == https://www.mediawiki.org/wiki/Future is unclear and developing > the new editor without a design documents is just a way to perpetuate the > problems of the current syntax. > > Operation Manager > E-mail: [email protected] > Mobil: +36 30 866 6706 > > > > Római Horizon Kft. > H-1039 Budapest > Királyok útja 291. D. ép. fszt. 2. > Tel: +36 1 492 1492 > Fax: +36 1 266 5529 > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Pavel Tkachenko > Sent: Wednesday, February 08, 2012 1:32 PM > To: Wikitext-l > Subject: Re: [Wikitext-l] Markup syntax > > Amir, > > Your idea doesn't sound that utopian or crazy to me but, IMO, it has its weak > points. > > First, it's a superstition that XML is the only standard way of representing > information. The fact that even after its heavy lobbying by > the-company-we-all-know-about languages like YAML still appear means that not > all people are happy with XML. Similarly, textile/markdown//bb-codes/wikitext > and a dozen of others including latex, *nix man pages, etc. are appearing > even after HTML has been around for decades. > > What is a standard? This is a set of rules. Strict ABNF schemes. UML, if you > please. Can you call Windows INI files "standard"? Yes, albeit they have just > a few entities. And YAML? TeX? Yes. And PDF? EPS? Yes, and they're even > unreadable by humans. > > Similarly, wiki markup can be standardized. Creole is meant to be a standard > but it's limited; however, the direction is right and can be voted for. I am > ready to personally standardize and unificate wiki markup if only to prove my > point. > > Second, by dividing people into those who "can write texts using a visual > editor" and those who "have to write texts using a storage format" you're > making the same discrimination towards "geeks" that "geeks" are currently > making towards "common folk" by providing nothing but a text field for > writing articles. > > Let's put this plain: XML and mostly (X)HTML (SGML at a whole) are storage > formats. This is why they have namespaces, DTD and other features. But they > are generic and while this is an advantage (even binary data can be stored in > some form there) when it comes in touch with humans things break or just > don't move. > > This is because XML and friends are not problem-based solutions. While I have > to agree that editing texts might be easier by some people using a rich > editor I cannot agree that editing them in plain text form must be limited to > storage formats. Have you tried hexediting an article? Having to perform > codepage conversions (read, layout changes) in your mind at the same time. > This is the same. > > Going further into this looks like speaking about personal taste for colors > and forms so I will just summarize it up: let's leave everyone with their > tool. We have three groups of "users": machines, who process the text - > they're fine with XML or BAML all alike; users, who need a visual editor to > "parse markup" as was said on the neighbor thread; and someone in between, > "geeks", who are enough humans to dislike XML and enough technicians to > despise WYSIWYG. > > This seems fair and not that big deal to implement because you'll get the > first and last "markups" ready by definition to have a working parser > (something to store trees in and something to input them using) and the > middle (visual editor) will come in naturally given the other two. > > Signed, > P. Tkachenko > > 2012/2/8 Amir E. Aharoni <[email protected]>: >> Honestly, if i'm allowed to speak out my crazy optimistic utopian >> dream, then: <crazy-optimistic-utopian-dream>i want the current-style >> wiki markup to disappear completely. I'm referring to *, '''''', {{}}, >> [[]] etc. It was very beneficial for the beginning, because it was for >> the most part more intuitive to type than <ul><li></li></ul>, >> <strong></strong> and <a href=""></a>, but for people who want >> easiness, the Visual Editor is supposed to provide it and after that >> most of them should never look back to the markup. >> >> For people who will want text-based markup, it should be mostly XHTML. >> So, <section>, <poem>, <source>, and <nowiki> are kinda XHTML so they >> can stay. *, '''''' and [[]] are not XHTML, and they can and should be >> replaced by XHTML, althogh. And {{}} needs its own markup, but it >> should be XHTML-like <template name="citation needed" />. >> >> So there. My idea of a bright wikifuture is less home-grown parsers >> and more standards. It's easier for the developers and works >> organically with the browsers. It's not necessarily easier for people >> who want to write articles in plain text with markup, but hey, they >> asked for it.</crazy-optimistic-utopian-dream> >> >> -- >> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי >> http://aharoni.wordpress.com “We're living in pieces, I want to live >> in peace.” – T. Moore > > _______________________________________________ > 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
