![[Home]](http://meatballwiki.org/meatball.gif)
MarkupSkin
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesWhat is a "markup skin" supposed to be?
Wiki engines could implement that users can choose which wiki markup they prefer for editing. At least for simple things like underlining or bold text it would be very easy to implement. Why should be we burden thousands of users with learning a different syntax if computers can translate very easily? Actually now I found out that at least a development for one direction already exists: In MoinMoin you can choose which parser should be used for a page. See http://moinmoin.wikiwikiweb.de/ProcessorMarket and http://moinmoin.wikiwikiweb.de/ParserMarket.
Alternative names: markup babel fish, markup translation.
1.1. Markup Skins Implementation
I began to realize from InfiniteMonkey that there is also room for an abstract WikiParserModel which would allow automated translations between the various WikiSyntaxes, a la the WikiXmlDtd. Actually, building a good parser model is necessary before building a WikiXmlDtd. The parser model may not fit very well with most of the translators out there, but it would be a good basis from which to consider a WikiMarkupStandard. Naturally, this statement now demands that I write the WikiParserModel, so I'm hesitant to write this. Perhaps now that I studying this field full time, it will be easier to produce. — SunirShah
If WikiMarkupStandard can succeed, this sounds like overkill to me. But maybe you just have to be a little more concrete about your idea and how that would help exactly. — ThomasWaldmann
Looking at an example solution, what if one were to accept an XHTML-like markup output such as that provided by Radeox, and simply write Radeox markup property files (describing the input and output regex's) for each syntax? Yes, I know this wouldn't solve the entire problem, but what if it solved say, 80% or 90% of the syntax translation problems? Given that Radeox also has a macro feature, it'd not be too hard to implement additional syntax-to-function features on top of the base syntax translation. I just know that a lot of attempts at abstraction are both overkill and impossible, given that abstraction relies on there truly being a common target model among all the implementations, which I'd suggest isn't true in wiki. Tackling this ad hoc isn't actually a bad direction in that case. — MurrayAltheim