Titleadopt mediawiki format
Date05-Feb-2007 15:53:47 EET
JSPWiki versionany
Submitter142.177.76.130
Idea CategoryMarkupIdea
Reference
Idea StatusNotAtAllANewIdea

There are now various efforts to standardize WikiMarkup.

If they succeed, they will eventually result in changes to all data maintained in JSPwiki. This should be minimized.

If they fail, the vast bulk of widely consulted mediawiki data in so many languages, the core of which corpus is at Wikipedia and related projects, will set a de facto standard. Some argue that this standard has already been set and that converters will not be able to deal with all the side cases arising in all languages in Wikipedia, cannot discern the original editors' intent, and that the namespace requires so much attention that there is no possibility of Wikipedia ever adopting name conventions that exclude characters that it allows. Others argue bitterly against supporting WikiWords in any form and would resist any standard that supported them.

English is also case-sensitive on all letters after the first, and disallows capitalization on all but proper nouns and acronyms. Mediawiki does likewise. This alone makes mediawiki names (and thus links) far more user friendly for an English speaking user than any competitors.

Because the success of any "standard" is in doubt, and because the vast bulk of data is in mediawiki format, JSPwiki should cease to support a distinct format and adopt mediawiki format native. If a standard emerges, then JSPwiki and mediawiki teams can cooperate to find all conversion cases and solve them all, possibly encouraging mediawiki to be rewritten in Java and merge with JSPwiki, making JSPwiki the dominant wiki. If a standard does not emerge, then JSPwiki will already be using the de facto standard and its users will have a choice of mediawiki / PHP or JSPwiki / Java. This will be the only such choice available and would amount to a multi-sourced standard, making JSPwiki and mediawiki both acceptable to corporate buyers who refuse to buy anything from only one vendor.

JSPwiki should make a great big noise of abandoning its native format for all the above reasons, and should state clearly that failing to deal with millions of articles in mediawiki format, and the dedicated community that is creating and updating them regularly, and has created the world's largest and most often consulted information resource, and which data is exported to many other sites, is not optional.

Getwiki, also, a mediawiki fork that supports importing of whole mediawiki corpus, has features that should be incorporated into both JSPwiki and mediawiki itself (Tikiwiki has more fine grained control over importation and could be next to adopt the de facto standard format).

If all four development teams (JSPwiki, mediawiki, getwiki, tikiwiki) declare in common that they intend to allow users to import data from public sources like wikipedia, clean it up in any of the wiki technologies for specialized or sector-specific use, then import from those to private wikis, they will attract the most knowledgeable and wise users, who seek exactly these capabilities. No other strategy will convince these users to adopt anything but getwiki/mediawiki. Until they see JSPwiki adopting mediawiki format, and maintaining a native format that is neither "the emerging standard" nor "the de facto standard" they will continue to correctly perceive its priorities as "wrong".

Changing code is easy. Changing data is hard.


Take a look at the CreolePageFilter. Creole is almost like MediaWiki format. Headings, link syntax etc. are the same. Still it will be supported by many other wiki engines.

--ChristophSauer, 5-Feb-2007


There is the wiki concept, and the wikipedia content.. being compatible with wikipedia as an early goal would be an immense boost for jspwiki, even if its not a main goal.

--davidm, 05-Feb-2007


I read a lot of definitive shoulds and should nots above — rather strident rhetoric — yet my experience on the Internet over the last 20 years or so has suggested that there is nothing definitive about popularity — it has little to do with usability, stability, longevity, or anything else. This is a bit like quoting web log statistics at people. Wikipedia is certainly the most popular wiki in the world, but it's hardly typical, and one might remember that the vast majority of its pages are edited by a relatively small number of people; the viewership is enormous whilst the editorship is not, so people's experience with the syntax isn't as wide as might be implied by the tone of your message, which is almost eschatological. In contrast, there are millions of people editing hundreds of thousands of wikis that aren't in Wikimedia format. The diversity of the wiki community may be seen as a bane, but advocating that JSPWiki dump its native format doesn't necessarily provide it or the larger wiki community with any real added benefit. Some of these are the same arguments made for Esperanto. If people want to use Wikimedia's notation they are much more likely to simply use the Wikimedia engine. (This coming from someone who's been previously involved in and an advocate for InterWiki and other interchange efforts.)

I rather doubt that due to Wikipedia's popularity its syntax will become an "emerging standard" or "de facto standard" for wikitext. Wikipedia is atypical, just as is Google. I was on both the IETF and W3C HTML Working Groups, developing specifications for HTML and XHTML that are widely understood as "standards", but in terms of real usage (i.e., actual conformance of the majority of web documents to their claimed specifications) could hardly be claimed to be either an "emerging standard" or "de facto standard" — and we're talking HTML here! So I simply don't see the arguments you make so strongly as being supported by any relevant evidence, other than the popularity of one atypical wiki site — no matter how popular.

Changing code is easy. Changing data is hard.
This statement has things completely backwards, so let's get one other thing straight: writing relatively bug-free, high quality code in a collaborative environment is not easy, it's extremely difficult — witness how few successful, stable, quality projects there are out there, even commercially-funded ones — whereas while changing data is not trivial, it's hardly difficult, as attested by the common import and export features of software packages, as well as tools such as awk, sed, XSLT, and many others. It's a lot harder to change human behaviour, and building a community of wiki users only to slap them in the face by changing the editing syntax they've grown accustomed to could hardly be a recommended action. The JSPWiki user and developer community has a substantial investment in its installed base of software, documentation, training, and expertise, and we'd be jeopardizing all of that by making the changes suggested above. This is likely true of most wiki communities, hence the resistance to the One Language For All arguments, which can become a distraction from doing other, more important, work.

-- MurrayAltheim


Guys, this is obviously a troll. Let it go. I see these "you must all adopt mediawiki/tikiwiki/foobarwiki or your wiki is DOOMED!" -people come up every now and then, and they always go away once they've had their rant.

(There are many obvious reasons why this discussion is, in the end, rather irrelevant, but people rarely stop to think about them. However, the way that the original article was written was so obnoxious that I couldn't be bothered to use any more of my time in responding.)

-- JanneJalkanen


It's fine for you to have your own thing going on, but I don't know why you'd want to discard someone else's considered opinion so rudely, compatibility is really not such a surprising thing to want. Maybe it's the server attacks. I hope you can get it together.

--davidm, 06-Feb-2007


I support this proposal.

The main obstacle to using Wikis for internal purposes are the different markup languages. It is difficult to move an internal wiki knowledge base to another wiki engine and everybody has to learn many wiki markup languages (for example because he works for many projects). Therefore we standardize on MediaWiki markup. The MediaWiki engine is ok and easy to install.

We would like to use JspWiki for our internal project wikis, but it is not possible because it uses yet another Wiki markup format and conversion is difficult.

--Christian Vester, 12-April-20076


Hmm... to try to satisfy everybody... why not propose that the folks who want to support Mediawiki (or other) markup formats create a pluggable mechanism/extension for JSPWiki, and then provide the various markup modules, as well as create the markup converters?

--SteveLin, 06-Jul-2007

Steve,

We already have nascent WikiCreole support in the 2.5.x development branch so it's demonstrably possible to build a MediaWiki parser as an alternative to the native one already in JSPWiki. If you're willing to do the coding, documentation, testing and provide maintenance on that code you're quite welcome to create that pluggable mechanism and the necessary markup converters. From my understanding of the core JSPWiki team we're all pretty busy with the project and our own associated projects so this is not a very high priority — we don't have spare cycles to devote to compatibility with other projects before getting our own done. If this is a real priority for someone, I can only suggest devoting the resources to make it happen, otherwise this will remain indefinitely in the realm of ideas.

-- MurrayAltheim, 06-July-2007


I'd have to go with Murray here. I don't think anyone from the core team has any interest whatsoever in the Mediawiki markup - we're all busy with more important things.

Besides, I think the discussion is pointless anyway. WikiMarkup as such is an aberrance which must go away, and we shall all move to WYSIWYG editing. So I would much rather get good editors than muck around in the incredible mess which comes when you try to support multiple markup languages.

--JanneJalkanen, 06-Jul-2007


And, in addition, adopting Mediawiki format would force us to limit our functionality to whatever Mediawiki offers. If we have more or fewer features, our markup would not be compatible, and you would be screwed in exactly the same, though far more subtle and annoying way.

WikiCreole is as far as I'm willing to go, because that should work across all engines in the future.

--JanneJalkanen, 06-Jul-2007

I just would like to add: we just released Creole 1.0 two days ago. Take a look at it, you will find many familiar elements with Mediawiki markup (Headings, links). A wiki offering creole therefore should make it also more appealing to Wikipedians.

--ChristophSauer, 06-Jul-2007


I agree that that we don't need one ring to rule them all. It makes sense to allow variants with each having a way to switch to or translate through a common standard like WikiCreole. The only annoying JSPWiki markup is the single-bracket links ([link]) where a single-bracket is often part of my notes or quick code excerpts.

--KeithMashinter, 07-Aug-2007

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-16) was last changed on 07-Aug-2007 08:20 by KeithMashinter