I saw we get a lot of troubles with wikitext. I wonder this idea is possible: we will concentrate to build a wysiwyg editor which produces xml-like content so that:
- people don't have to know any wiki language - developer is able to forget wikitext and its complexity
To prove that it is possible with a friend of mine, I had write a xml-like language for wiki (in Vietnamese). I can ask him to translate it into English (because I'm not really good in English).
On 18/02/2008, Minh Lê Ngọc cumeo89@gmail.com wrote:
I saw we get a lot of troubles with wikitext. I wonder this idea is possible: we will concentrate to build a wysiwyg editor which produces xml-like content so that:
people don't have to know any wiki language developer is able to forget wikitext and its complexityTo prove that it is possible with a friend of mine, I had write a xml-like language for wiki (in Vietnamese). I can ask him to translate it into English (because I'm not really good in English).
There is the obvious issue with backwards compatibility there, although that can be overcome with work. The other major issue is that no WYSIWYG system is likely to be as powerful as wikitext, or as quick and easy to use (for experienced users). WYSIWYG is certainly much easier for new users, but once you are familiar with wikitext, it is generally better.
So I think that once you are familiar with xml, it's good too, right? I think we'll need a part of XHTML, not all of them, and some additional tags only. It won't be too difficult.
2008/2/19, Thomas Dalton thomas.dalton@gmail.com:
On 18/02/2008, Minh Lê Ngọc cumeo89@gmail.com wrote:
I saw we get a lot of troubles with wikitext. I wonder this idea is possible: we will concentrate to build a wysiwyg editor which produces xml-like content so that:
people don't have to know any wiki language developer is able to forget wikitext and its complexityTo prove that it
is
possible with a friend of mine, I had write a xml-like language for wiki
(in
Vietnamese). I can ask him to translate it into English (because I'm not really good in English).
There is the obvious issue with backwards compatibility there, although that can be overcome with work. The other major issue is that no WYSIWYG system is likely to be as powerful as wikitext, or as quick and easy to use (for experienced users). WYSIWYG is certainly much easier for new users, but once you are familiar with wikitext, it is generally better. _______________________________________________ Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
On 18/02/2008, Minh Lê Ngọc cumeo89@gmail.com wrote:
So I think that once you are familiar with xml, it's good too, right? I think we'll need a part of XHTML, not all of them, and some additional tags only. It won't be too difficult.
Wikitext is designed to be much easier to use than XML. Even if it's not much easier to write, it's much easier to read, and therefore much easier to edit.
There is the obvious issue with backwards compatibility there, although that can be overcome with work. The other major issue is that no WYSIWYG system is likely to be as powerful as wikitext, or as quick and easy to use (for experienced users). WYSIWYG is certainly much easier for new users, but once you are familiar with wikitext, it is generally better.
Actually, I don't think these are even the worst problem. The worst problem is that the wysiwyg editor would have to cover the full range of what wikitext can do now - and it would get very complex and hard in exactly the same places: a bit of text styling is simple enough, in wikitext, in a new parser, and in wysiwyg. But editing nested tables is already a challange with "real" word processors, not to mention web-based editors. And when we get into designing complex templates, using "magic" sections like noinclude, using complex parser functions and template parameters, and, most of all, using special constructs defined by extensions, things get extremly complex. For example, extensions could rely on xml represenations, but they would have to provide gui interaction elements to create and edit them. I truely believe that trying to buld a gui framework for this would be much much harder than all the tricky stuff a good wikitex parser has to deal with. With a "simple" parser, as well as with "naive" wysiwyg like fckedit, it's easy enough to get to 90% of what wikitext can do. Getting to the 99.9% we need to make this usable for wikipedia is HARD. And doing it as a gui system is harder, imho.
-- Daniel
On 18/02/2008, Daniel Kinzler daniel@brightbyte.de wrote:
There is the obvious issue with backwards compatibility there, although that can be overcome with work. The other major issue is that no WYSIWYG system is likely to be as powerful as wikitext, or as quick and easy to use (for experienced users). WYSIWYG is certainly much easier for new users, but once you are familiar with wikitext, it is generally better.
Actually, I don't think these are even the worst problem. The worst problem is that the wysiwyg editor would have to cover the full range of what wikitext can do now
That's what I mean by "no WYSIWYG system is likely to be as powerful as wikitext".
I agree with all of you. A WYSIWYG editor can not replace Wikitext. In some cases, wikitext is a programing language like Java and NetBeans can't program Java for Java programmers.
However, there 2 aspects of using MediaWiki: daily use (users may be novice, know little of Wikitext, edit simple pages) and template writing (experienced users write complicated code in templates for others to use). With the first one, WYSIWYG is a wonderful feature, with the second one, it's clumsy. So, a WYSIWYG editor should only cover some features of wikitext like: simple page representation, reference, template inclusion, extension call, page preview, categories, inter-wiki and leave others like: parser functions, magic variables, noinclude, includeonly, parameters...
Through this mailing-list, I see that we are struggling with Wikitext, which is a time-consuming work. What I suggest is, instead of wasting more time, we can change to XML, which is clearer, easy to parse, easy to understand and easy to extend.
2008/2/19, Thomas Dalton thomas.dalton@gmail.com:
On 18/02/2008, Daniel Kinzler daniel@brightbyte.de wrote:
There is the obvious issue with backwards compatibility there, although that can be overcome with work. The other major issue is that no WYSIWYG system is likely to be as powerful as wikitext, or as quick and easy to use (for experienced users). WYSIWYG is certainly much easier for new users, but once you are familiar with wikitext, it is generally better.
Actually, I don't think these are even the worst problem. The worst
problem is
that the wysiwyg editor would have to cover the full range of what
wikitext can
do now
That's what I mean by "no WYSIWYG system is likely to be as powerful as wikitext".
Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
On 2/20/08, Minh Lê Ngọc cumeo89@gmail.com wrote:
I agree with all of you. A WYSIWYG editor can not replace Wikitext. In some cases, wikitext is a programing language like Java and NetBeans can't program Java for Java programmers.
If wikitext is a programming language, god help us. It's supposed to be a simple, intuitive replacement for complex languages like HTML.
However, there 2 aspects of using MediaWiki: daily use (users may be novice, know little of Wikitext, edit simple pages) and template writing (experienced users write complicated code in templates for others to use). With the first one, WYSIWYG is a wonderful feature, with the second one, it's clumsy. So, a WYSIWYG editor should only cover some features of wikitext like: simple page representation, reference, template inclusion, extension call, page preview, categories, inter-wiki and leave others like: parser functions, magic variables, noinclude, includeonly, parameters...
Which is to say, that if there is a WYSIWYG editor, there should be a way of accessing the underlying XML directly.
Through this mailing-list, I see that we are struggling with Wikitext, which is a time-consuming work. What I suggest is, instead of wasting more time, we can change to XML, which is clearer, easy to parse, easy to understand and easy to extend.
Heh. Replacing the wikitext parser with a better wikitext parser is a pretty significant change. Replacing it with an XML parser...wow. You aim big.
I think realistically the problem is that open source works relatively well for language compilers. People can add features simply by extending syntax etc, and it works. However, who amongst us has the ability to really implement and maintain a high quality WYSIWYG editor? It's hard, really hard. And a WYSIWYG editor with editable syntax, now you're talking about a tool like frontpage, dreamweaver etc. This is not a task for a couple of full time developers and a bunch of hobbyists.
Steve
Steve Bennett wrote:
On 2/20/08, Minh Lê Ngọc cumeo89@gmail.com wrote:
I agree with all of you. A WYSIWYG editor can not replace Wikitext. In some cases, wikitext is a programing language like Java and NetBeans can't program Java for Java programmers.
If wikitext is a programming language, god help us. It's supposed to be a simple, intuitive replacement for complex languages like HTML.
With ParserFunctions, you have to take a lot of care not to end up with a turing complete language. We are pretty close. As soon as someone adds a while loop construct (or allows full recursion), we got it.
However, there 2 aspects of using MediaWiki: daily use (users may be novice, know little of Wikitext, edit simple pages) and template writing (experienced users write complicated code in templates for others to use). With the first one, WYSIWYG is a wonderful feature, with the second one, it's clumsy. So, a WYSIWYG editor should only cover some features of wikitext like: simple page representation, reference, template inclusion, extension call, page preview, categories, inter-wiki and leave others like: parser functions, magic variables, noinclude, includeonly, parameters...
Which is to say, that if there is a WYSIWYG editor, there should be a way of accessing the underlying XML directly.
So it's nto really about replacing wikitext with wysiwyg. But replacing wikitextwith XML, and also having wysiwyg editing for *some* aspects.
Through this mailing-list, I see that we are struggling with Wikitext, which is a time-consuming work. What I suggest is, instead of wasting more time, we can change to XML, which is clearer, easy to parse, easy to understand and easy to extend.
Heh. Replacing the wikitext parser with a better wikitext parser is a pretty significant change. Replacing it with an XML parser...wow. You aim big.
XML is designed as a data exchange format. Good XML (that is: using XML constructs for all structuring and semantic annotation) is extremely annoying to edit by hand. It wasn't made for that. Consider this:
{| class="prettytable" | ! foo ! bar |--- | style="align:right" | {{bla|blubb|x=frobble}} | {{#if:{{{1}}}|the '''[[bla|thing]]'''}} |}
as compared to
<table class="prettytable"> <thead> <tr> <th>foo</th> <th>bar</th> </tr> </thead> <tbody> <tr> <td style="align:right"> <template name="bla"> <param>blubb</param> <param name="x">frobble</param> </template> </td> <td> <function name="if"> <arg><paramref name="1"/></arg> <paramter>the <b><link target="bla">thing</link></b></parameter> </template> </td> </tr> </tbody> </table>
now, which is easier to read? which is easier to edit?
XML is great as an exchange format. And it's easy to parse (actually, it's quite tricky in the details, and rather slow too, but at least we have standard libraries for it)
I would *not* want to have to write/edit XML structures by hand. Not even as a template editing expert.
Mind you, having a clean mapping of wikitext from/to XML would be a VERY good thing. But that requires a real wikitext parser.
I think realistically the problem is that open source works relatively well for language compilers. People can add features simply by extending syntax etc, and it works. However, who amongst us has the ability to really implement and maintain a high quality WYSIWYG editor? It's hard, really hard. And a WYSIWYG editor with editable syntax, now you're talking about a tool like frontpage, dreamweaver etc. This is not a task for a couple of full time developers and a bunch of hobbyists.
Exactly. Just think of commonly used extensions like <cite> (not to mention insanely complex stuff like EasyTimeline). The extension editor would have to write complex GUI interaction that ties into a complex GUI framework, so it is possible to edit these constructs in a wysiwyg environment.
Also, any wysiwyg editor would have to take extreme care not to damage any structures it does not "understand". People could try to edit a template using such an editor, and screw it up completely, without ever noticing. I hear them say: "but i only fixed a typo".... yay.
Again: writing a good, robust and flexible wysiwyg editing framework would be a LOT harder (especially wrt extensions) than getting the wikitext parser done. IMHO it's like this: getting 90% is easy with both, a formal grammar, and a wysiwyg editor (based on XML or whatever). Getting the last 10% into the prmal gramamer is HARD. Getting the last 10% right in a visual editor is pretty much impossible, even if you don't need "template designed" ability - the features used in "normal" articles are bad enough.
-- Daniel
On 2/20/08, Daniel Kinzler daniel@brightbyte.de wrote:
LOT harder (especially wrt extensions) than getting the wikitext parser done. IMHO it's like this: getting 90% is easy with both, a formal grammar, and a wysiwyg editor (based on XML or whatever). Getting the last 10% into the prmal gramamer is HARD. Getting the last 10% right in a visual editor is pretty much impossible, even if you don't need "template designed" ability - the features used in "normal" articles are bad enough.
What's hard about the grammar exactly? It's been pretty slow, mostly because of difficulties with ANTLR, but I don't think there are any more major difficulties in the wikitext grammar exactly. Most of the issues I've raised on this list seem like they're big ("zomg is that asterisk a list or a literal!") but they're ambiguous in precious few actual real examples.
Time to take this grammar and do something with it.
Steve
On Thu, Feb 21, 2008 at 01:16:22AM +1100, Steve Bennett wrote:
Time to take this grammar and do something with it.
Build a parser with it, run it against the corpus, and see how often each individual rule pukes?
Cheers, -- jra
On 2/21/08, Jay R. Ashworth jra@baylink.com wrote:
On Thu, Feb 21, 2008 at 01:16:22AM +1100, Steve Bennett wrote:
Time to take this grammar and do something with it.
Build a parser with it, run it against the corpus, and see how often each individual rule pukes?
Ok. I've actually done a bit of that, but I guess I should ramp up the scale. It can be hard to detect pukage without actually generating XHTML and comparing it, though.
Generally, though, the answer is "not often". Flip through some random wikitext. You'll find that a very small number of rules amount for the vast majority of actual use. Though that may change once I have to contend with the body of templates. People don't use tables much. They don't use HTML tags or entities much. They almost never use magic links (especially PMID - wtf is that about it). They almost never use horizontal rules, HTML comments and rarely even extensions like <ref>
Steve
On Thu, Feb 21, 2008 at 01:12:34PM +1100, Steve Bennett wrote:
On 2/21/08, Jay R. Ashworth jra@baylink.com wrote:
On Thu, Feb 21, 2008 at 01:16:22AM +1100, Steve Bennett wrote:
Time to take this grammar and do something with it.
Build a parser with it, run it against the corpus, and see how often each individual rule pukes?
Ok. I've actually done a bit of that, but I guess I should ramp up the scale. It can be hard to detect pukage without actually generating XHTML and comparing it, though.
Generally, though, the answer is "not often". Flip through some random wikitext. You'll find that a very small number of rules amount for the vast majority of actual use. Though that may change once I have to contend with the body of templates. People don't use tables much. They don't use HTML tags or entities much. They almost never use magic links (especially PMID - wtf is that about it). They almost never use horizontal rules, HTML comments and rarely even extensions like <ref>
I don't know if you remember it at this point, Steve, but one of the reasons I threw "won't someone *please* build us a grammar-driven parser" up in the air (and thanks, BTW :-), was precisely to get a fairly reliable count of how often each possible bit'o'grammer appears in, say, en.wp, so as to get a feeling for what will break if the syntax is restricted slightly...
That is to say that I concur with your instinct: 90/10 rule, I would guess, here.
Cheers, -- jra
On 2/21/08, Jay R. Ashworth jra@baylink.com wrote:
I don't know if you remember it at this point, Steve, but one of the reasons I threw "won't someone *please* build us a grammar-driven parser" up in the air (and thanks, BTW :-), was precisely to get a fairly reliable count of how often each possible bit'o'grammer appears in, say, en.wp, so as to get a feeling for what will break if the syntax is restricted slightly...
That is to say that I concur with your instinct: 90/10 rule, I would guess, here.
Ah, yes.
Well, it really should be pretty easy to produce some stats like "in this corpus, there are 850 inline links, 560 images, 227 bullet list items" etc. It will be harder to detect subtle things like "things which closely resemble, but aren't, inline images" or "external links wrapped in double square brackets by some moron".
Steve
On Thu, Feb 21, 2008 at 03:43:54PM +1100, Steve Bennett wrote:
On 2/21/08, Jay R. Ashworth jra@baylink.com wrote:
I don't know if you remember it at this point, Steve, but one of the reasons I threw "won't someone *please* build us a grammar-driven parser" up in the air (and thanks, BTW :-), was precisely to get a fairly reliable count of how often each possible bit'o'grammer appears in, say, en.wp, so as to get a feeling for what will break if the syntax is restricted slightly...
That is to say that I concur with your instinct: 90/10 rule, I would guess, here.
Ah, yes.
Well, it really should be pretty easy to produce some stats like "in this corpus, there are 850 inline links, 560 images, 227 bullet list items" etc. It will be harder to detect subtle things like "things which closely resemble, but aren't, inline images" or "external links wrapped in double square brackets by some moron".
Oh sure. Building the test harness will be an iterative process. But once someone does, we'll actually have not only a formal grammar, but a second reference implementation...
Cheers, -- jra
Through this mailing-list, I see that we are struggling with Wikitext, which is a time-consuming work. What I suggest is, instead of wasting more time, we can change to XML, which is clearer, easy to parse, easy to understand and easy to extend.
You want an XML based language for describing the formatting of webpages? Basically, you're suggesting we switch to XHTML (with more some features removed and a few added). XHTML is much harder to learn and use than wikitext, even for experienced users.
Thomas Dalton wrote:
Through this mailing-list, I see that we are struggling with Wikitext, which is a time-consuming work. What I suggest is, instead of wasting more time, we can change to XML, which is clearer, easy to parse, easy to understand and easy to extend.
You want an XML based language for describing the formatting of webpages? Basically, you're suggesting we switch to XHTML (with more some features removed and a few added). XHTML is much harder to learn and use than wikitext, even for experienced users.
XHTML would only be good for the formatting aspects. It can't represent parser functions, template calls, etc. XML lets you mix and match vocabularies, of course.
-- Daniel
On Wed, 2008-02-20 at 13:25 +0100, Daniel Kinzler wrote:
Thomas Dalton wrote:
Through this mailing-list, I see that we are struggling with Wikitext, which is a time-consuming work. What I suggest is, instead of wasting more time, we can change to XML, which is clearer, easy to parse, easy to understand and easy to extend.
You want an XML based language for describing the formatting of webpages? Basically, you're suggesting we switch to XHTML (with more some features removed and a few added). XHTML is much harder to learn and use than wikitext, even for experienced users.
XHTML would only be good for the formatting aspects. It can't represent parser functions, template calls, etc. XML lets you mix and match vocabularies, of course.
-- Daniel
For the average user I believe Wikitext to be the easiest to learn, however I am not an expert on the technical aspects and ressources used by using Wikitext. On the subject of creating a WYSIWYG editor, I don't believe this is the best solution. Instead, the current editor could be expanded to include forms similar to many popular Blog softwares, e.g. Wordpress.
For example, if a user wants to include an image this is quite easy for an experienced user, however for a beginner it can be quite complicated. If instead a dialog would appear asking for various parameters, for example size, thumb, description and alignment, this would make it a lot more simpler - no matter if the result get's displayed as Wikitext or WYSIWYG.
Ian [[User:Poeloq]]
--- Ian A Holton Blog: http://www.ianholton.net
On Wed, Feb 20, 2008 at 10:34:38AM +0000, Thomas Dalton wrote:
Through this mailing-list, I see that we are struggling with Wikitext, which is a time-consuming work. What I suggest is, instead of wasting more time, we can change to XML, which is clearer, easy to parse, easy to understand and easy to extend.
You want an XML based language for describing the formatting of webpages? Basically, you're suggesting we switch to XHTML (with more some features removed and a few added). XHTML is much harder to learn and use than wikitext, even for experienced users.
No, he suggests giving up the ability/necessity to use a text format as users at all, going solely to a wysiayg, excuse me, wysiwyg editor.
Cause I'll love that a lot on my blackberry.
Cheers, -- jra
On Mon, Feb 18, 2008 at 08:46:59PM +0000, Thomas Dalton wrote:
On 18/02/2008, Daniel Kinzler daniel@brightbyte.de wrote:
There is the obvious issue with backwards compatibility there, although that can be overcome with work. The other major issue is that no WYSIWYG system is likely to be as powerful as wikitext, or as quick and easy to use (for experienced users). WYSIWYG is certainly much easier for new users, but once you are familiar with wikitext, it is generally better.
Actually, I don't think these are even the worst problem. The worst problem is that the wysiwyg editor would have to cover the full range of what wikitext can do now
That's what I mean by "no WYSIWYG system is likely to be as powerful as wikitext".
This, combined with the "powerusers can do it better in text" argument, the source of the purposefully pejorative replacement observation:
What You See Is ALL You Get.
Cheers, -- jra
Minh Lê Ngọc wrote:
I saw we get a lot of troubles with wikitext. I wonder this idea is possible: we will concentrate to build a wysiwyg editor which produces xml-like content so that:
* people don't have to know any wiki language * developer is able to forget wikitext and its complexityTo prove that it is possible with a friend of mine, I had write a xml-like language for wiki (in Vietnamese). I can ask him to translate it into English (because I'm not really good in English).
The problem is not to have a wysiwig editor and/or a xml-based markup. The problem is to have that compatible in both directions with current wikitext.
The problem is not to have a wysiwig editor and/or a xml-based markup. The problem is to have that compatible in both directions with current wikitext.
I think that's why the suggestion was the ditch wikitext altogether (at least that's what I understood by "give up wikitext"). That would only require one-off one-way conversion, which is much easier.
I know that a lot of wikitext has been written but I think the problem is: which work is harder, complete wikitext and build wysiwyg or build xml-based markup, convert to it and build wysiwyg upon it. I think convert to xml is not too difficult because almost of wikitext constructs have already been converted to html day after day. We only have to convert some like inclusion, reference, parser function... And build a wysiwyg editor with xml-like markup is much easier than one with wikitext.
2008/2/19, Platonides platonides@gmail.com:
Minh Lê Ngọc wrote:
I saw we get a lot of troubles with wikitext. I wonder this idea is possible: we will concentrate to build a wysiwyg editor which produces xml-like content so that:
* people don't have to know any wiki language * developer is able to forget wikitext and its complexityTo prove that it is possible with a friend of mine, I had write a xml-like language for wiki (in Vietnamese). I can ask him to translate it into English (because I'm not really good in English).
The problem is not to have a wysiwig editor and/or a xml-based markup. The problem is to have that compatible in both directions with current wikitext.
Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
On 18/02/2008, Minh Lê Ngọc cumeo89@gmail.com wrote:
I know that a lot of wikitext has been written but I think the problem is: which work is harder, complete wikitext and build wysiwyg or build xml-based markup, convert to it and build wysiwyg upon it. I think convert to xml is not too difficult because almost of wikitext constructs have already been converted to html day after day. We only have to convert some like inclusion, reference, parser function... And build a wysiwyg editor with xml-like markup is much easier than one with wikitext.
Conversion from wikitext to XHTML is easy. Converting back is likely to be quite a bit less easy, but might be worth a try.
- d.
Hah, you actually think that the WikiText conversion to XHTML is a good conversion to use as a base for a XML version.
I suggest you actually look over the source of a parsed page before you make insane assumptions like that.
From [[Wikipedia:Talk:Main Page]]
Errors in /In the news/
* The Wikileaks entry says it is "offline", but this is not true. As our Wikileaks http://en.wikipedia.org/wiki/Wikileaks article says, it is still online at its IP address. --Jedravent http://en.wikipedia.org/wiki/User:Jedravent (talk http://en.wikipedia.org/wiki/User_talk:Jedravent) 16:51, 19 February 2008 (UTC)
I just tried the links. Wikileaks.org is still off-line, but Wikileaks.be (a mirror site?) is accessible. If you think the wrong link has been placed on the Wikileaks http://en.wikipedia.org/wiki/Wikileaks article, please discuss this at Talk:Wikileaks http://en.wikipedia.org/wiki/Talk:Wikileaks. Thanks. --PFHLai http://en.wikipedia.org/wiki/User:PFHLai (talk http://en.wikipedia.org/wiki/User_talk:PFHLai) 17:39, 19 February 2008 (UTC)
Still, Wikileaks is not "offline", as it can still be accessed. --Jedravent http://en.wikipedia.org/wiki/User:Jedravent (talk http://en.wikipedia.org/wiki/User_talk:Jedravent) 18:39, 19 February 2008 (UTC)
I agree, the headline is misleading. Wikileaks is not offline. Their previous primary domain name, wikileaks.org is no longer available by court order. If we are going to keep this, we need to explain the situation without misleading people Nil Einne http://en.wikipedia.org/wiki/User:Nil_Einne (talk http://en.wikipedia.org/wiki/User_talk:Nil_Einne) 20:21, 19 February 2008 (UTC)
Wikileaks entry should say "the Wikileaks.org site is unavailable, however the site remains online an can be reached via its mirrors.Thalia42 http://en.wikipedia.org/w/index.php?title=User:Thalia42&action=edit (talk http://en.wikipedia.org/wiki/User_talk:Thalia42) 20:16, 19 February 2008 (UTC)
What's the output?
<h2><span class="editsection">[<a href="/w/index.php?title=Wikipedia:Main_Page/Errors&action=edit&section=T-2" title="Wikipedia:Main Page/Errors">edit</a>]</span> <span class="mw-headline">Errors in the summary of <i>Today's featured article</i> on the Main Page</span></h2>
<p><a name="Errors_in_In_the_news" id="Errors_in_In_the_news"></a></p> <h2><span class="editsection">[<a href="/w/index.php?title=Wikipedia:Main_Page/Errors&action=edit&section=T-3" title="Wikipedia:Main Page/Errors">edit</a>]</span> <span class="mw-headline">Errors in <i>In the news</i></span></h2> <ul> <li>The Wikileaks entry says it is "offline", but this is not true. As our <a href="/wiki/Wikileaks" title="Wikileaks">Wikileaks</a> article says, it is still online at its IP address. --<a href="/wiki/User:Jedravent" title="User:Jedravent">Jedravent</a> (<a href="/wiki/User_talk:Jedravent" title="User talk:Jedravent">talk</a>) 16:51, 19 February 2008 (UTC)</li>
</ul> <dl> <dd>I just tried the links. Wikileaks.org is still off-line, but Wikileaks.be (a mirror site?) is accessible. If you think the wrong link has been placed on the <a href="/wiki/Wikileaks" title="Wikileaks">Wikileaks</a> article, please discuss this at <a href="/wiki/Talk:Wikileaks" title="Talk:Wikileaks">Talk:Wikileaks</a>. Thanks. --<a href="/wiki/User:PFHLai" title="User:PFHLai">PFHLai</a> (<a href="/wiki/User_talk:PFHLai" title="User talk:PFHLai">talk</a>) 17:39, 19 February 2008 (UTC) <dl> <dd>Still, Wikileaks is not "offline", as it can still be accessed. --<a href="/wiki/User:Jedravent" title="User:Jedravent">Jedravent</a> (<a href="/wiki/User_talk:Jedravent" title="User talk:Jedravent">talk</a>) 18:39, 19 February 2008 (UTC)
<dl> <dd>I agree, the headline is misleading. Wikileaks is not offline. Their previous primary domain name, wikileaks.org is no longer available by court order. If we are going to keep this, we need to explain the situation without misleading people <a href="/wiki/User:Nil_Einne" title="User:Nil Einne">Nil Einne</a> (<a href="/wiki/User_talk:Nil_Einne" title="User talk:Nil Einne">talk</a>) 20:21, 19 February 2008 (UTC)</dd> </dl> </dd> </dl> </dd> </dl> <dl> <dd>Wikileaks entry should say "the Wikileaks.org site is unavailable, however the site remains online an can be reached via its mirrors.<a href="/w/index.php?title=User:Thalia42&action=edit" class="new" title="User:Thalia42">Thalia42</a> (<a href="/wiki/User_talk:Thalia42" title="User talk:Thalia42">talk</a>) 20:16, 19 February 2008 (UTC)</dd>
</dl>
: is both for indentation, and for definitions. Take this: ;Foo: A commonly used expression used in technical discussions to refer to an example. ;Bar: Another commonly used expression used in technical discussions which often accommodates Foo. And this: Here's my first comment, so who's making the second? ~~~~ :I am, who's making the third? ~~~~ ::That would be me. ::Did you know we even like to spread comments over multiple lines? ~~~~ :Ya, we sometimes drop backwards in our indentation to! ~~~~ ::You guys do know that you're actually using definition lists to create your indentation, right? ~~~~ :::Er, what's a definition list? ~~~~ ::::Markup used in HTML to create a list of word and definition pairs. ~~~~ :::::Eh, I thought we were using WikiText, not HTML? ~~~~
Now... parse that through the parser, and tell me what is a set of word/definition pairs, and what is indentation? No sane parser can do something like that. And if you want anything remotely sane for XML editing, which isn't sane, you'll need to distinguish between the two.
Oh ya... <p>This is a paragraph.</p> <p>This is another paragraph.</p> <p>Now tell me, who used double lines to create those paragraphs. And who actually used the <p/> tag?</p> <p>Honestly, I don't want to need to use a <p/> when writing markup every time I want a new paragraph.</p> <p>And using a &lt;p/&gt; to describe the syntax is absolutely disturbing.</p>
Now... Tell me who is more insane? The person trying to create a XML language for editing. Or the person who is driven up the wall by trying to stare at the mangled <>'s inside their "document" that is supposed to be something they can edit.
And don't tell me that it'll all be fixed by a WYSIWYG editor which will let people edit without seeing the tags. That's bull because there are plenty of people around who don't have JavaScript enabled, don't have a good enough browser to handle it, can't access a computer with a browser better than IE for Mac, are running IE 5.5, or are editing using a mobile browser which will never be able to handle WYSIWYG. Honestly tell me you can handle the death threats you'll get by dropping support for a fair fraction of MediaWiki end users and forcing them into a black hole to try and edit...
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
David Gerard wrote:
On 18/02/2008, Minh Lê Ngọc cumeo89@gmail.com wrote:
I know that a lot of wikitext has been written but I think the problem is: which work is harder, complete wikitext and build wysiwyg or build xml-based markup, convert to it and build wysiwyg upon it. I think convert to xml is not too difficult because almost of wikitext constructs have already been converted to html day after day. We only have to convert some like inclusion, reference, parser function... And build a wysiwyg editor with xml-like markup is much easier than one with wikitext.
Conversion from wikitext to XHTML is easy. Converting back is likely to be quite a bit less easy, but might be worth a try.
- d.
Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
2008/2/20, DanTMan dan_the_man@telus.net:
<h2><span class="editsection">[<a href="/w/index.php?title=Wikipedia:Main_Page/Errors&action=edit&section=T-2" title="Wikipedia:Main Page/Errors">edit</a>]</span> <span class="mw-headline">Errors in the summary of <i>Today's featured article</i> on the Main Page</span></h2>
<p><a name="Errors_in_In_the_news" id="Errors_in_In_the_news"></a></p> <h2><span class="editsection">[<a href="/w/index.php?title=Wikipedia:Main_Page/Errors&action=edit&section=T-3" title="Wikipedia:Main Page/Errors">edit</a>]</span> <span class="mw-headline">Errors in <i>In the news</i></span></h2> <ul> <li>The Wikileaks entry says it is "offline", but this is not true. As our <a href="/wiki/Wikileaks" title="Wikileaks">Wikileaks</a> article says, it is still online at its IP address. --<a href="/wiki/User:Jedravent" title="User:Jedravent">Jedravent</a> (<a href="/wiki/User_talk:Jedravent" title="User talk:Jedravent">talk</a>) 16:51, 19 February 2008 (UTC)</li>
</ul> <blockquote>I just tried the links. Wikileaks.org is still off-line, but Wikileaks.be (a mirror site?) is accessible. If you think the wrong link has been placed on the <a href="/wiki/Wikileaks" title="Wikileaks">Wikileaks</a> article, please discuss this at <a href="/wiki/Talk:Wikileaks" title="Talk:Wikileaks">Talk:Wikileaks</a>. Thanks. --<a href="/wiki/User:PFHLai" title="User:PFHLai">PFHLai</a> (<a href="/wiki/User_talk:PFHLai" title="User talk:PFHLai">talk</a>) 17:39, 19 February 2008 (UTC) <dl> <dd>Still, Wikileaks is not "offline", as it can still be accessed. --<a href="/wiki/User:Jedravent" title="User:Jedravent">Jedravent</a> (<a href="/wiki/User_talk:Jedravent" title="User talk:Jedravent">talk</a>) 18:39, 19 February 2008 (UTC)
<dl> <dd>I agree, the headline is misleading. Wikileaks is not offline. Their previous primary domain name, wikileaks.org is no longer available by court order. If we are going to keep this, we need to explain the situation without misleading people <a href="/wiki/User:Nil_Einne" title="User:Nil Einne">Nil Einne</a> (<a href="/wiki/User_talk:Nil_Einne" title="User talk:Nil Einne">talk</a>) 20:21, 19 February 2008 (UTC)</dd> </dl> </dd> </dl> </dd> </dl> <dl> <dd>Wikileaks entry should say "the Wikileaks.org site is unavailable, however the site remains online an can be reached via its mirrors.<a href="/w/index.php?title=User:Thalia42&action=edit" class="new" title="User:Thalia42">Thalia42</a> (<a href="/wiki/User_talk:Thalia42" title="User talk:Thalia42">talk</a>) 20:16, 19 February 2008 (UTC)</dd>
</dl>
It is not necessary. I think it should like this:
<h2>Errors in <i>In the news</i></h2>
<ul> <li> The Wikileaks entry says it is "offline", but this is not true. As our <a wtitle="Wikileaks">Wikileaks</a> article says, it is still online at its IP address.<a wtitle="User:Jedravent">Jedravent</a> (<a wtitle="User talk:Jedravent">talk</a>) 16:51, 19 Febuary 2008 (UTC) </li> </ul>
<blockquote> I just tried the links. <a href="http://Wikileaks.org">Wikileaks.org</a> is still off-line, but <a href="http://Wikileaks.be">Wikileaks.be</a> (a mirror site?) is accessible. If you think the wrong link has been placed on the Wikileaks article, please discuss this at Talk:Wikileaks. Thanks. --<a wtitle="User:PFHLai">PFHLai</a> (<a wtitle="User talk:PFHLai>talk</a>) 17:39, 19 February 2008 (UTC)
<blockquote> Still, Wikileaks is not "offline", as it can still be accessed. --<a wtitle="User:Jedravent">Jedravent</a> (<a wtitle="User talk:Jedravent">talk</a>) 18:39, 19 February 2008 (UTC)
<blockquote> I agree, the headline is misleading. Wikileaks is not offline. Their previous primary domain name, wikileaks.org is no longer available by court order. If we are going to keep this, we need to explain the situation without misleading people <a wtitle="User:Nil_Einne">Nil Einne</a> (<a wtitle="User talk:Nil_Einne">talk</a>) 20:21, 19 February 2008 (UTC)
</blockquote> </blockquote> </blockquote>
<blockquote> Wikileaks entry should say "the <a href="http://Wikileaks.org">Wikileaks.org</a> site is unavailable, however the site remains online an can be reached via its mirrors.<a wtitle="User:Thalia42">Thalia42</a> (<a wtitle="User talk:Thalia42">talk</a>) 20:16, 19 February 2008 (UTC) </blockquote>
Isn't it too difficult for you?
Daniel Kinzler daniel@brightbyte.de
XHTML would only be good for the formatting aspects. It can't represent parser functions, template calls, etc. XML lets you mix and match vocabularies, of course.
I have never said that we'll use native XHTML. I said that Wikitext is too loose, making it difficult to parse and we waste a lot of work hours for it. What I suggest is a XML-based markup because it's less painful and I can prove with you, it can represent anything Wikitext can. We just only add some tags as: <if>, <include>, <value-of> and even <for-each>,... It's sound complicated but it isn't more complicated than Wikitext at all. It's nothing more than Wikitext structures rewritten in XML style. It's good because it's clearer, easier to parse and not too difficult to read.
You stated "I think convert to xml is not too difficult because almost of wikitext constructs have already been converted to html day after day." However, converting WikiText to XML and converting it to XHTML meant only for display are completely different things.
Now covering all the possible bases that could be made on that I can derive...
There's no way to convert WikiText directly into XML in the way you imply without a proper grammar. Which if created, will already void the point of converting over. And you can't use the converted XHTML to come up with a good way of representing the data inputed.
Next in line, is the notion of ditching WikiText without converting it. Honestly, is that even sane... There are over ... articles on Wikipedia alone. Not to mention the other large sites like Wikia. Ditching a language used everywhere like that, is like removing all definition of the Chinese language and telling them that Chinese can no longer be used. You get riots... Now if you say that those sites can stick with WikiText. Then there's little point in creating a new language, because there's little point in a new parser language if Wikipedia is not using it. That's like telling the WikiMedia Foundation to cut off Wikipedia's upgrades because it's getting to old.
Then there's the mention of a XML equivalent of WikiText. You mean, replace things like: :Comment With: <indent>Comment</indent> Or: <dl>Comment</dl> I hardly see how that is any different, as a simple regex will easily match both. Any further, and we're doing it in a way which we can't convert existing WikiText into tags... And then we're right back at the notion of ditching WikiText without converting it, which as I've already explained is insane.
Then there's the notion of XML structures being cleaner, easier to parse, and not to difficult to read. And half that is bull. Sure, a XML language is good for a parser. But cleaner... That's starting to push it. And not to difficult to read... That's just crap. There's no way a pile of <>'s all over the text is anywhere near easy to read, and to someone who doesn't even understand XML that's just bull. WikiText was designed to be able to be editable by nearly anyone. An XML language will never be clean enough for the average person to edit. And like I said, don't state any crap about them using WYSIWYG. There are plenty of users who can't use a WYSIWYG editor and will need to be able to edit plain text. And a XML based language isn't anywhere near friendly for them.
~Daniel Friesen(Dantman) of:
-The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Minh Lê Ngo.c wrote:
2008/2/20, DanTMan dan_the_man@telus.net:
<h2><span class="editsection">[<a href="/w/index.php?title=Wikipedia:Main_Page/Errors&action=edit&section=T-2" title="Wikipedia:Main Page/Errors">edit</a>]</span> <span class="mw-headline">Errors in the summary of <i>Today's featured article</i> on the Main Page</span></h2>
<p><a name="Errors_in_In_the_news" id="Errors_in_In_the_news"></a></p> <h2><span class="editsection">[<a href="/w/index.php?title=Wikipedia:Main_Page/Errors&action=edit&section=T-3" title="Wikipedia:Main Page/Errors">edit</a>]</span> <span class="mw-headline">Errors in <i>In the news</i></span></h2> <ul> <li>The Wikileaks entry says it is "offline", but this is not true. As our <a href="/wiki/Wikileaks" title="Wikileaks">Wikileaks</a> article says, it is still online at its IP address. --<a href="/wiki/User:Jedravent" title="User:Jedravent">Jedravent</a> (<a href="/wiki/User_talk:Jedravent" title="User talk:Jedravent">talk</a>) 16:51, 19 February 2008 (UTC)</li>
</ul> <blockquote>I just tried the links. Wikileaks.org is still off-line, but Wikileaks.be (a mirror site?) is accessible. If you think the wrong link has been placed on the <a href="/wiki/Wikileaks" title="Wikileaks">Wikileaks</a> article, please discuss this at <a href="/wiki/Talk:Wikileaks" title="Talk:Wikileaks">Talk:Wikileaks</a>. Thanks. --<a href="/wiki/User:PFHLai" title="User:PFHLai">PFHLai</a> (<a href="/wiki/User_talk:PFHLai" title="User talk:PFHLai">talk</a>) 17:39, 19 February 2008 (UTC) <dl> <dd>Still, Wikileaks is not "offline", as it can still be accessed. --<a href="/wiki/User:Jedravent" title="User:Jedravent">Jedravent</a> (<a href="/wiki/User_talk:Jedravent" title="User talk:Jedravent">talk</a>) 18:39, 19 February 2008 (UTC)
<dl> <dd>I agree, the headline is misleading. Wikileaks is not offline. Their previous primary domain name, wikileaks.org is no longer available by court order. If we are going to keep this, we need to explain the situation without misleading people <a href="/wiki/User:Nil_Einne" title="User:Nil Einne">Nil Einne</a> (<a href="/wiki/User_talk:Nil_Einne" title="User talk:Nil Einne">talk</a>) 20:21, 19 February 2008 (UTC)</dd> </dl> </dd> </dl> </dd> </dl> <dl> <dd>Wikileaks entry should say "the Wikileaks.org site is unavailable, however the site remains online an can be reached via its mirrors.<a href="/w/index.php?title=User:Thalia42&action=edit" class="new" title="User:Thalia42">Thalia42</a> (<a href="/wiki/User_talk:Thalia42" title="User talk:Thalia42">talk</a>) 20:16, 19 February 2008 (UTC)</dd>
</dl>
It is not necessary. I think it should like this:
<h2>Errors in <i>In the news</i></h2>
<ul> <li> The Wikileaks entry says it is "offline", but this is not true. As our <a wtitle="Wikileaks">Wikileaks</a> article says, it is still online at its IP address.<a wtitle="User:Jedravent">Jedravent</a> (<a wtitle="User talk:Jedravent">talk</a>) 16:51, 19 Febuary 2008 (UTC) </li> </ul>
<blockquote> I just tried the links. <a href="http://Wikileaks.org">Wikileaks.org</a> is still off-line, but <a href="http://Wikileaks.be">Wikileaks.be</a> (a mirror site?) is accessible. If you think the wrong link has been placed on the Wikileaks article, please discuss this at Talk:Wikileaks. Thanks. --<a wtitle="User:PFHLai">PFHLai</a> (<a wtitle="User talk:PFHLai>talk</a>) 17:39, 19 February 2008 (UTC)
<blockquote> Still, Wikileaks is not "offline", as it can still be accessed. --<a wtitle="User:Jedravent">Jedravent</a> (<a wtitle="User talk:Jedravent">talk</a>) 18:39, 19 February 2008 (UTC)
<blockquote> I agree, the headline is misleading. Wikileaks is not offline. Their previous primary domain name, wikileaks.org is no longer available by court order. If we are going to keep this, we need to explain the situation without misleading people <a wtitle="User:Nil_Einne">Nil Einne</a> (<a wtitle="User talk:Nil_Einne">talk</a>) 20:21, 19 February 2008 (UTC)
</blockquote> </blockquote> </blockquote>
<blockquote> Wikileaks entry should say "the <a href="http://Wikileaks.org">Wikileaks.org</a> site is unavailable, however the site remains online an can be reached via its mirrors.<a wtitle="User:Thalia42">Thalia42</a> (<a wtitle="User talk:Thalia42">talk</a>) 20:16, 19 February 2008 (UTC) </blockquote>
Isn't it too difficult for you?
Daniel Kinzler daniel@brightbyte.de
XHTML would only be good for the formatting aspects. It can't represent parser functions, template calls, etc. XML lets you mix and match vocabularies, of course.
I have never said that we'll use native XHTML. I said that Wikitext is too loose, making it difficult to parse and we waste a lot of work hours for it. What I suggest is a XML-based markup because it's less painful and I can prove with you, it can represent anything Wikitext can. We just only add some tags as: <if>, <include>, <value-of> and even <for-each>,... It's sound complicated but it isn't more complicated than Wikitext at all. It's nothing more than Wikitext structures rewritten in XML style. It's good because it's clearer, easier to parse and not too difficult to read.
Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
On 21/02/2008, DanTMan dan_the_man@telus.net wrote:
There's no way to convert WikiText directly into XML in the way you imply without a proper grammar. Which if created, will already void the point of converting over. And you can't use the converted XHTML to come up with a good way of representing the data inputed. Next in line, is the notion of ditching WikiText without converting it. Honestly, is that even sane... There are over ... articles on Wikipedia alone. Not to mention the other large sites like Wikia. Ditching a language used everywhere like that, is like removing all definition of the Chinese language and telling them that Chinese can no longer be used. You get riots... Now if you say that those sites can stick with WikiText. Then there's little point in creating a new language, because there's little point in a new parser language if Wikipedia is not using it. That's like telling the WikiMedia Foundation to cut off Wikipedia's upgrades because it's getting to old.
The actual state of things is:
1. Wikitext is literally defined as "whatever the present software does." This is bad. 2. There have been several attempts to write a grammar. The latest one is looking promising for completeness (though ANTLR is slow and buggy). 3. A replacement grammar can be used for third-party implementations (WYSIWYG, XML, etc) with perfect fidelity. 4. Any replacement grammar will only replace the present implementation if it (a) covers present behaviour sufficiently (b) is fast enough.
Minh Lê Ngọc's reasoning is quite correct, but we need a replacement that is (a) sufficiently complete (whatever "sufficient" is) (b) works *better* than the present one. Then we can keep wikitext in all its kludgy glory *and* do XML versions and good WYSIWYG editors that aren't just WYSIAYG and so forth.
Current status of ANTLR-based parser: somewhere between promising vapourware and unreleased early alpha.
- d.
On 2/21/08, David Gerard dgerard@gmail.com wrote:
- Wikitext is literally defined as "whatever the present software
does." This is bad.
- unless whatever the present software does is wrong.
- There have been several attempts to write a grammar. The latest one
is looking promising for completeness (though ANTLR is slow and buggy).
- If I said that, I think I was wrong. ANTLRworks is slow and buggy. I think ANTLR itself is probably ok, particularly once the grammar itself is stabilised. It would be good to have something to benchmark against though - does mediawiki report how long it takes to *parse* a page?
- A replacement grammar can be used for third-party implementations
(WYSIWYG, XML, etc) with perfect fidelity.
Right.
- Any replacement grammar will only replace the present
implementation if it (a) covers present behaviour sufficiently (b) is fast enough.
Grammars don't replace parsers. Parsers replace parsers. There's a big gap between what I've done so far (write a grammar) and what is needed (write a parser and XHTML generator).
Current status of ANTLR-based parser: somewhere between promising vapourware and unreleased early alpha.
If you mean "parser" then definitely vapourware. If you mean "grammar" then, yes, early alpha.
Steve
2008/2/22, Steve Bennett stevagewp@gmail.com:
On 2/21/08, David Gerard dgerard@gmail.com wrote:
- Wikitext is literally defined as "whatever the present software
does." This is bad.
- unless whatever the present software does is wrong.
- There have been several attempts to write a grammar. The latest one
is looking promising for completeness (though ANTLR is slow and buggy).
- If I said that, I think I was wrong. ANTLRworks is slow and buggy. I
think ANTLR itself is probably ok, particularly once the grammar itself is stabilised. It would be good to have something to benchmark against though - does mediawiki report how long it takes to *parse* a page?
- A replacement grammar can be used for third-party implementations
(WYSIWYG, XML, etc) with perfect fidelity.
Right.
- Any replacement grammar will only replace the present
implementation if it (a) covers present behaviour sufficiently (b) is fast enough.
Grammars don't replace parsers. Parsers replace parsers. There's a big gap between what I've done so far (write a grammar) and what is needed (write a parser and XHTML generator).
Current status of ANTLR-based parser: somewhere between promising vapourware and unreleased early alpha.
If you mean "parser" then definitely vapourware. If you mean "grammar" then, yes, early alpha.
Steve
Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
If you're about to complete Wikitext grammar, so I have nothing to say any more. I just worried that we use too much of time in completing it. However I'll still build my own implementation of MW use XML. Hope people will enjoy it.
Steve Bennett wrote:
- There have been several attempts to write a grammar. The latest one
is looking promising for completeness (though ANTLR is slow and buggy).
- If I said that, I think I was wrong. ANTLRworks is slow and buggy. I
think ANTLR itself is probably ok, particularly once the grammar itself is stabilised. It would be good to have something to benchmark against though - does mediawiki report how long it takes to *parse* a page?
Yes, it does. It usually shows the total time to serve tha page, but you can make it give you the full time spenta on each function. http://flake.defau.lt/pics/mediawiki.png
On 2/22/08, Platonides platonides@gmail.com wrote:
Yes, it does. It usually shows the total time to serve tha page, but you can make it give you the full time spenta on each function. http://flake.defau.lt/pics/mediawiki.png
How?
Steve
Steve Bennett wrote:
On 2/22/08, Platonides wrote:
Yes, it does. It usually shows the total time to serve tha page, but you can make it give you the full time spenta on each function. http://flake.defau.lt/pics/mediawiki.png
How?
Steve
Using mediawiki's profiling functions http://www.mediawiki.org/wiki/How_to_debug#Profiling
2008/2/21, DanTMan dan_the_man@telus.net:
I hardly see how that is any different, as a simple regex will easily match both. Any further, and we're doing it in a way which we can't convert existing WikiText into tags... And then we're right back at the notion of ditching WikiText without converting it, which as I've already explained is insane.
Then there's the notion of XML structures being cleaner, easier to parse, and not to difficult to read. And half that is bull. Sure, a XML language is good for a parser. But cleaner... That's starting to push it. And not to difficult to read... That's just crap. There's no way a pile of <>'s all over the text is anywhere near easy to read, and to someone who doesn't even understand XML that's just bull. WikiText was designed to be able to be editable by nearly anyone. An XML language will never be clean enough for the average person to edit. And like I said, don't state any crap about them using WYSIWYG. There are plenty of users who can't use a WYSIWYG editor and will need to be able to edit plain text. And a XML based language isn't anywhere near friendly for them.
You forgot to add some shits, with or without them, your writing can't get
dirtier.
On 2/22/08, Minh Ngoc Le cumeo89@gmail.com wrote:
You forgot to add some shits, with or without them, your writing can't get dirtier.
Hey, be nice. (A message from your list moderator.)
Steve
On Tue, Feb 19, 2008 at 01:33:29AM +0700, Minh L? Ng???c wrote:
I think convert to xml is not too difficult because almost of wikitext constructs have already been converted to html day after day.
Installed Base.
In the abstract you may be correct.
But Mediawiki *must* support Wikipedia, and converting 2 million plus articles simply isn't going to happen -- I gave the idea up about 8 months back up *the mailing list archive*, which I suggest you explore; this has already been hashed out.
IE: PINCH!
Cheers, -- jra
wikitext-l@lists.wikimedia.org