Click here to edit contents of this page.
Click here to toggle editing of individual sections of the page (if possible). Watch headings for an "edit" link when available.
Append content without editing the whole page source.
Check out how this page has evolved in the past.
If you want to discuss contents of this page - this is the easiest way to do it.
View and manage file attachments for this page.
A few useful tools to manage this Site.
See pages that link to and include this page.
Change the name (also URL address, possibly the category) of the page.
View wiki source for this page without editing.
View/set parent page (used for creating breadcrumbs and structured layout).
Notify administrators if there is objectionable content in this page.
Something does not work as expected? Find out what you can do.
General Wikidot.com documentation and help section.
Wikidot.com Terms of Service - what you can, what you should not etc.
Wikidot.com Privacy Policy.
Why would we support the syntax of a competing Wiki engine? Not only does additional syntax for the same purposes create confusion, but we're Wikidot! We should do things the Wikidot way.
Actually, there are good reasons, and implementing more than one language (quite a task) would make Wikidot stand out more:
1) It makes relocating a wiki from another service to Wikidot a whole lot easier. In fact, due to the language difference, moving a wiki of any significant size is almost untenable.
2) Depending how it is done, it could actually remove confusion. If someone must actively participate in more than one wiki on different providers, they have to remember the syntax of both. Or maybe they have to even use a third one… For example, our corporate wiki uses Atlassian Confluence, there are a lot of local Twiki's, I use wikidot for a lot of personal sites, and it's easy to see that I might have to do stuff in a Mediawiki site… that's 4 syntaxes, all similar but different.
An idea popped into my head about how I'd architect something like this. It would not just be "set the site's language" as that is far too restrictive — the advantage of allowing more than one language for this purpose is a per-user setting, not per-site. Therefore, the key to success is allowing each user to define their language. Thus, one would define a "base language"—and perhaps that is not a wiki-like language at all. If designing it from scratch, I would make this the fastest possible language to turn into HTML — or maybe even just make it HTML, perhaps with some extensions.
Then, what people enter is code in their choice of language. Saving it would "compile" it into the site language. Editing a page would de-compile it before presenting it to the user. Voila… everyone has their language of choice.
Nahhhh
An eloquent and stout defense of the "One Wikidot, One Syntax" point of view.
In an ideal world, Wikidot would be extraordinarily good at importing content from other sources: wikis, web sites (HTML->wikidot), documents, pigeons. And it would be terribly, apologetically bad at exporting it any way other than as Wikidot.
Portfolio