The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Wiki for Joel on Software translations?

I'm thinking that it might be a good idea to just set up a Wiki for all the Joel on Software translated articles. That way the volunteers who translate articles could publish them themselves without emailing them to me and waiting around for me to publish them to the web.

Does anyone have any advice on how to do this?

I'd like it to look as much like wikipedia as possible, with pictures, real links (no CamelCase requirement), and maintaining a history of changes so vandalism can be quickly undone. Most importantly, I'd like it to be self-organizing so that, ideally, once we set up the servers, it just sort of magically populates itself with high quality translations of the Joel on Software articles :-)

Any ideas or suggestions?
Joel Spolsky Send private email
Tuesday, August 16, 2005
I assume this means we can finally get Klingon versions?
Eric Sink Send private email
Tuesday, August 16, 2005
David Send private email
Tuesday, August 16, 2005
I really like flexwiki ( ). It has very customizable layout support. By default is uses CamelCase, but it isn't required, and is a lot easier to read and edit than the wikipedia engine.
Stefan Rusek Send private email
Tuesday, August 16, 2005
ok, which of those is good? :)

We have Windows and NetBSD servers so .Net is not a requirement.
Joel Spolsky Send private email
Tuesday, August 16, 2005
Build one into FogBugz?


Seriously though, a Jira/Confluence-type combination for FogBugz would be really cool. Why not just get some more interns and let it rip?
Patrick Foley Send private email
Tuesday, August 16, 2005
Masiosare Send private email
Tuesday, August 16, 2005
If you want it to look like Wikipedia then MediaWiki is the obvious choice. Its major advantage is also that the markup language is the same as Wikipedia's -- there are a lot of different markup dialects out there.

For smaller Wikis I like to use engines that save the content in files as opposed to a database, but ease of setup is probably not the most important factor for you (otherwise I'd recommend Oddmuse/Usemod).

DokuWiki is another popular choice, it is apparently optimized towards documentation projects; but I haven't really used it enough to be able to point out what difference that makes (maybe someone else has more insights).

A word of advice: It makes sense to use a popular engine that is actively maintained, Wikis (as any complex software) might open up security holes on your webserver. Look at the respective developer website to see how they communicate open vulnerabilities, and how regularly they distribute patches.
Martin Dittus
Tuesday, August 16, 2005
I'm sort of scared of MediaWiki because it's probably terribly complex and optimized to run only on Wikipedia's environment... I wonder how hard it would be to get running on an arbitrary server?
Joel Spolsky Send private email
Tuesday, August 16, 2005
I've gotten MediaWiki running on a generic WAMP server in under 20 minutes.  Works like a champ.
Boofus McGoofus Send private email
Tuesday, August 16, 2005
Sorry -- I've got it up on a LAMP server -- setting up a WAMP server (and getting WordPress and MediaWiki running) is my project for next month.
Boofus McGoofus Send private email
Tuesday, August 16, 2005
My vote goes to Mediawiki too, mainly because 1 gazillion people already know how to use it from the Wikipedia. Plus there is a huge organization behind it so the chances of it being neglected are slim.

PHP and MySQL seems about all that's required. State of the art hardware seems to be required though ;)

"Slow performance has been reported on systems where the whole site is on a single Pentium 133 with 48MB of RAM."
Jan Derk
Tuesday, August 16, 2005
Flexwiki is very extendible and had a great format. and It supports great templating and formatting that when combined with CSS, you get a great possiblities. It is actively being developed and supports either file based storage or MS SQL storage.
Stefan Rusek Send private email
Tuesday, August 16, 2005
I second the "don't be scared" sentiment.
MediaWiki is super easy to set up. MySQL is the only slight pain.
Tuesday, August 16, 2005
Any Wiki's that runs on IIS, MSDE, ASP (or APS.Net) and Win 2k/XP/2003, takes 5 minutes to install and just, you know, works?
HS Send private email
Tuesday, August 16, 2005
+1 for Mediawiki.

I set one up on my $6 per month linux web host in about 30 minutes.  I don't know PHP and barely know linux.  They made it incredibly simple. (Ok, it's not something my mom would install, but it's incredibly simple for an open-source PHP app.)

Give it a try.  You'll have it going in no time.

Kyle Send private email
Tuesday, August 16, 2005
XWiki is great for translation management!
see also many other interesting features:
(OSS, LGPL, Java)
Stéphane Laurière Send private email
Tuesday, August 16, 2005
We use MediaWiki, the software behind Wikipedia on our intranet.

It works very well and was easy to set up with two exceptions: 1) altering the look is tricky because of the complexity of the stylesheets and 2) enabling the LaTeX markup (not important for your application) has some strange requirements, like ocaml.

The momentum that Wikipedia gives this engine makes it a good choice.  A huge population already knows the markup and the interface.  It has an active user community and they've removed most of the  Wikipedia-specific stuff from the standard distribution.  For your application, it may be especially well suited because Wikipedia has already figured out how to handle dealing with the same article in multiple languages.
Matthew Simoneau Send private email
Tuesday, August 16, 2005
I'm not sure if you're interested in a hosted solution, but we'd be happy to offer space at Wikispaces (  We've tried to stay clean and easy to use, CamelCase is optional, and there's full visual history with easy reverts to old versions.  Pages can be edited either using a visual editor or wikitext.  We're adding support for external domain names and for spaces without Google ads.

Otherwise, MediaWiki is a good option if you're looking to maintain the wiki in-house and want the full gamut of features.  Unless it starts drawing monster traffic, it'll run fine on moderate hardware.

James Byers Send private email
Tuesday, August 16, 2005
MediaWiki works well for Wikipedia, but was less suitable for our (where I work) intranet than I originally thought:

 * Most things actually work!
 * It scales in every possible direction
 * It has all the hacker/DOS protection you need built in.
 * Well established markup

 * Most things aren't that useful unless you're writing an encyclopedia. (Timeline? Latex?)
 * The format is established, but not newbie friendly.
 * Relatively hard to extend, unless you're willing to invest a lot of time.
 * Default setup doesn't work well with older (IE4, IE5, IE5.5) browsers; Perhaps it's been fixed since.

Eventually, we chose MoinMoin. It has most (all?) of the important features of MediaWiki.

 * It scales, though not as well - 10000 pages should be no problem, but 1000000 could pose one. Should be enough for most intranets.
 * It has multiple language support, which we don't use but should work for JOS.
 * subjective: has simpler markup
 * Is significantly easier to extend -- I added an "IFRAME" markup element in 5 minutes, without knowing too much about MoinMoin.
 * Has internal code highlight for many languages

MediaWiki is the heavy artillery, but MoinMoin is good enough for most sites.

+1 for MoinMoin.
Ori Berger
Tuesday, August 16, 2005
Another vote for MediaWiki. Looks and functions just like Wikipedia, because it's what powers Wikipedia. Only requires PHP and a MySQL database. I got it up and running on my website using only an FTP client and my browser. Total time: 20 minutes from the time I read Pete at Rasterweb's post about how easy it was to the time I had the wiki up and running.

Related links:
Josh Bancroft Send private email
Tuesday, August 16, 2005
MediaWiki definitely. We went with it for our customer self-support site ( and I really don't have any complaints. As far as setup, I think we had it running inside of 30 minutes. Getting all the under-the-hood stuff customized the way we wanted was perhaps another hour. All-in-all great product.
Jason J. W. Williams Send private email
Tuesday, August 16, 2005
I had been using TWiki for a while but I have now switched to MediaWiki.

TWiki is really powerful, however I found it harder to install. It is based on Perl and text files.

MediaWiki is not as powerful but it is easier to install in a Windows box. It is based on PHP and MySQL.

I think that MediaWiki will do the work.
Héctor Sansores Send private email
Tuesday, August 16, 2005
When you need somethink small and easy - but with all desired features like history etc. - I'd recommend DokuWiki. Install procedure is as easy as to upload files to the server and the big plus is that doesn't require database - you simply edit text files. You can even upload a whole directory structure with text files and DokuWiki will automatically create its web pages (every directory is one category, every text file is one web page). Files are easily readable / downloadable even after total application crash (which I haven't encountered, of course :) ).

DokuWiki is under development, has some good user control features (you can make some parts of Wiki private or accessible only to registered users) and could fit for your needs.

Tuesday, August 16, 2005
Um, how would you know if an article had been vandalized if you don't know the language?
Colm O'Connor Send private email
Tuesday, August 16, 2005
I have setup two instances of MediaWiki.  One runs the Mac OS X Server FAQ and the other the internal web site for my project at work.  The former runs under Unix, the latter, Windows.  Both took less than 30 minutes to install (although PHP on Windows can be involved).

What I like about MediaWiki:
* An RSS feed of changes.  This way I can track changes and see the spam that comes through.
* Simple to setup.
* Well-designed UI.
* You can lock it down so that only registered users can make modifications (this has effectively cut my spam to nothing on the Mac OS X Server FAQ).

What I do not like:
* MediaWiki's markup language.  Something about using double-single quotes (e.g., '') to denote emphasis seems weird to me.  But then again, the only non-HTML markup language I like is Markdown , so I might be a litte biased.

I also just used TextPattern to setup my web log .  It is certainly not a wiki, but more of a cross between blog software and CMS software.  There is a little bit of a learning curve in getting it setup (it took me a couple of days to get everything the way I wanted it).  The jury is still out on whether or not I would recommend it.
Aaron Jensen Send private email
Tuesday, August 16, 2005
To James Byers ( )

nice web site. i would be very wary of close-source proprietary solution, tough. it's dated (c) 2005, it could dissapear (c) 2005 too... ;) it lacks a more detailed who/what/where FAQ, including questions such as:

it seems the business model is google-ad revene, correct? what if the site dissapears tomorrow? do you provide some sort of backup to a whole directory tree / section (including the history, of course)? is it exportable to other wiki formats, and if so, which ones? in order to attract users you have to give them the option to get out. if it's good - they'll stay. but if they can't get out, they won't even try to use it ...

i'm posting these questions here because i'm sure other readers would be interested in the answers too...
Tuesday, August 16, 2005
"Are you finding it too time-consuming to add content to your web site, and edit it once it's there? CityDesk completely automates the whole process of formatting pages, creating your home page and navigation, and publishing the site to a web server."

Does this mean CityDesk isn't cutting it anymore?
At first impression, it would appear that adding a Wiki to the web site would split management of the site into two, the CityDesk part and the Wiki part. This is anathema to the CityDesk idea, isn't it?
I realize, the current CityDesk database-centered architecture doesn't work for website editable content but maybe you should pull CityDesk in that direction.
Tuesday, August 16, 2005
Another vote for MediaWiki. Very easy to try out on Windows:

1. get some easy-to install WAMP platform like XAMPP:

2. few clicks and waiting, and requirements (Apache, MySql, PHP) are done

3. get MediaWiki tarbal:

3. unpack it in xampp/htdocs

4. point your browser to localhost/where_you_put_wiki, fill simple form, copy config file

And that's it, done. Afterwards, it's just like (empty) Wikipedia.
postfilter Send private email
Tuesday, August 16, 2005
You could also try PmWiki, which runs practically anywhere because it only needs PHP. 

Relevant features:
* Internationalization-friendly, with a bunch of UI translations already.  See for more information.
* Customizable -- for example, it takes very little work to have different UI languages in different languages for different wiki groups
* GUI edit buttons to insert markup in the edit box.
* quick reference for markup displayed below edit box
* Monobook Mediawikil-look-alike skin at
* pages are stored by default in flat text files, but there is an add-on to store them in a database instead.
Bronwyn Boltwood Send private email
Tuesday, August 16, 2005
If you like MediaWiki but don't want to set up your own server, try
It hosts a ton of individual wiki sites. For example,
Don Kirkby
Tuesday, August 16, 2005
++ for uses mediawiki engine, can't go wrong with that one. in the worst case, you can just download the backup zip file and run it yourself...

list of free wiki hosts (currently about 15):
Tuesday, August 16, 2005
In regards to the earlier questions about Wikispaces: wikitext backups of public spaces are available to all, we encourage the use of Creative Commons content licensing, and we have API access high on our todo list.  Your data is your data; we're here to provide a great service and not get in the way.

I don't want to take this discussion too far off the original topic; please feel free to follow up at or

James Byers Send private email
Tuesday, August 16, 2005
I've been very happy with MediaWiki. It's not perfect, and I agree at first it seems kind of complicated, but it gets the job done and then some.

Our DBA had MediaWiki up in less than an hour on our Windows web server: He had never setup a wiki of any kind before.

Making the CSS and php presentation files to integrate it with our website look took me less than half a day. After a while we wanted to restrict (hide) certain pages and in less than an hour I found a patch and had it installed.

Feel free to email me if you would like to discuss our MediaWiki project further.
Jade Ohlhauser Send private email
Tuesday, August 16, 2005

I set up my own PBWiki (they say its "as easy to make as a peanut butter sandwich") and it took a few seconds.

I've been emailing David, the guy who created it, and a changelog is coming within the week. Very responsive support, feature requests have been implemented within hours, and it's free.
Michael Sartori Send private email
Tuesday, August 16, 2005
There's also OpenWiki ( ), which is fairly old and basically abandonware, but it runs on classic ASP, is easy to install and customize, and fully-featured. It uses both CamelCase and [[Media Wiki]]-style links.
Mark Cidade Send private email
Tuesday, August 16, 2005
Finally, onother vote: my former company (Net Integration - uses a fork of WikkiTikkiTavi called GracefulTavi.  They're FogBugz users, and apart from that the management is highly influenced by your writings (especially as regards to hiring practices and project scheduling) so I think using their wiki would be highly appropriate.  GracefulTavi is quite easy to set up (PHP+MySql), and although tends to use CamelCase for links, it also supports Wikipedia-style links.

Joe Mason Send private email
Tuesday, August 16, 2005
I've been using phpwiki [] - it's small, flexible, easy to setup, and has a wikimedia look alike mode.  It can write to flat files, berkley db, or an SQL database. It's wriiten in PHP (obviously), which could be good or bad depending on your perspective.  The good news is it's doesn't require the dreaded register_globals to be on, so it's at least somewhat secure.  I haven't really looked at it from a security perspective just yet, but apparently the NYT are using it - which bodes well.
Carl Perry Send private email
Tuesday, August 16, 2005
I'll add a vote for dokukwiki. One thing that seems to have been neglected is the wiki markup languages. It's worth writing a document in two or three of these formats and seeing how they compare usability wise. In my opinion dokuwiki has by far the most human-readable format.
Myles Byrne Send private email
Tuesday, August 16, 2005
I can't comment on WikiMedia as I have never used it, but PHPWiki has been fairly stable ever since I set it up 6 months ago and had it updated many times a day. If you are looking for ease of use and trivia; embedment of media, I suggest you go with a different package.
Roy Schestowitz Send private email
Tuesday, August 16, 2005
Have you looked at Instiki? It's written in Ruby, and "There Is No Step Three™!"
Ken Weber Send private email
Tuesday, August 16, 2005
I run MediaWiki for my personal wiki, it was really easy to set up. Just need access to a DB like MySQL and run the install script. It's not difficult.

Feel free to play:
Stewart Johnson Send private email
Tuesday, August 16, 2005
Myles Byrne: "One thing that seems to have been neglected is the wiki markup languages. It's worth writing a document in two or three of these formats and seeing how they compare usability wise."

After having used a variety of Wikis I definitely agree -- compare the markups before you make a choice. Using Wikipedia syntax helps getting some users started, but not that many people have actually edited Wikipedia articles, and other markup dialects might be more suited to your preferences.

Design a simple test page that contains the layout elements you want to use (text, headlines, screenshots, lists, definitions, info boxes, tables, inbound and outbound links, topics, etc) and compare how it is written in different markup dialects.
Martin Dittus
Tuesday, August 16, 2005
Slightly offtopic: can anyone explain why wikis don't use a basic html editor widget and html, rather than some in between markup to produce html? Why learn a 2nd way to write a strong tag when you can write a strong tag, or click a button to insert a strong tag? Makes no sense at all.
stylo~ Send private email
Tuesday, August 16, 2005
There are all sort of reasons for using simplified markup and not WYSIWYG interfaces (as clean as they may be) or plain HTML.
<li>Firstly, there is the issue of security such as off-site linking. You need to provide a subset of features. Having said that, this can be prevented by imposing restrictions on whichever composition language/method you choose</li>
<li>Secondly, you have the issue of consistency. I have a friend who manages the content of a site and I can't tell you how many times he did something stupid that broke the integrity of the site, which I then had to fix. More restrictive means less things to go wrong.</li>
Roy Schestowitz Send private email
Wednesday, August 17, 2005
Joel, why don't you just rely on machine translation instead of manually rewriting all of your stuff?  It's not perfect, but it has gotten better over the years.

I use Google and Altavista's translation services for Third Goal, a community blog for Peace Corps volunteers.

<a href="">Third Goal's translate icons</a>.

I added the feature <a href="">this week</a>, so we'll see how it goes.
Jason Pearce Send private email
Wednesday, August 17, 2005
Another vote for MediaWiki.  More important than an easy install is that it has been easy to update for some time: It includes an intelligent update script that tests for changes to the databases, config files, etc. and does the dirty work for you.

Will also allow the use of the excellent Wikipedia Firefox extension & is already setup to allow translations.  The default install uses the Monobook skin, just as Wikipedia does.
Wednesday, August 17, 2005
Another trivial-to-install wiki is AspWiki, or WikiAsp, I forget which. Probably not good for something the scale of JoS.

As for why wiki markup is good:

 * It's easy to explain.
 * This list would expand to <UL><LI>blah</LI>...</UL>
 * And the user doesn't need to understand.
 * But users can do some sophisticated markup things pretty easily.

True, rich editors might be nicer, but then you've got to figure out how to expose the metadata all over again.

Apparently some wikis do have rich editors.
mb Send private email
Wednesday, August 17, 2005
>* It's easy to explain.
>* This list would expand to <UL><LI>blah</LI>...</UL>
>* And the user doesn't need to understand.

Point is, then you do have to understand that, rather than clicking on the list icon which everyone knows!

OK, back to regular programming.
Wednesday, August 17, 2005
>>> Build one into FogBugz?
Yes, yes, yes!!!
Vladimir Golovin Send private email
Wednesday, August 17, 2005
My vote goes for MediaWiki. We're writing a manual for our upcoming software, and tried several Wikis for this purpose. WYSIWYG Wikis we tried all looked unstable and somewhat weird, so we decided to try MediaWiki. After a day, all of us (me and two tech writers) got used to the syntax, and since then everything has been great.
Vladimir Golovin Send private email
Wednesday, August 17, 2005
My vote goes for MediaWiki as well. I set it up in 30 minutes and didn't have any problem getting it configured.
David Send private email
Wednesday, August 17, 2005
+1 for PmWiki ( Very simple to install (only PHP is required), doesn't need database (flat files), nice markup (and you can very easily change it in the config file) and lots of skins.
Aras Pranckevicius Send private email
Wednesday, August 17, 2005
Some random thoughts;

- Pick one that stores documents on the filesystem not the database. Aside from the performance overhead etc. of DB vs filesystem and that (IMO) there's something fundamentally "wrong" about placing documents in a table, it's alot easier to administer documents by hand when their stored as files (i.e. if in need, File > Open).

- Take a good look at how the wiki parser works. Too frequently parsers are not well enough abstracted, being strongly tied to outputting HTML and parsing the document in multiple scans. Perhaps most important is the question - "If I decide to ditch this wiki, how easily can I convert the content to something I can use?"

- Require users authenticate themselves (vs. free for all). That will do alot to prevent wiki spam (which is a problem). I've yet to see a wiki that is capable of removing an old patch to a document so, unless it was the last revision, it will require manual editing.

- Expect to have to create some structure for the wiki, at least to start with. Most contributed updates will be changes to existing stuff rather than new documents.

- Following from "structure", choose a wiki that helps you with this. Older wikis simply dumped pages into a single global "namespace", making them very hard for users to browse other than by searching. There are wikis around now that have some kind of concept of "namespaces" which in turn allows generating of a structured "sitemap"

- Try writing some documents with the wiki's syntax. Is it more or less intuitive / easy to remember?

- Is is being actively developed / maintained?

- And of course, UTF-8 (which in reality means pick one where the main developers are not native English speakers)...

Now for the hard sell ;) Would recommend Dokuwiki: (downloads: IMO meets all of the above requirements. Bias warning: I did some modification to it's parser (

In particular, think the point on the advantages of filesystem vs. db for storing documents is illustrated well by this:

It may even be possible to run Dokuwiki native under .NET with help from - haven't tried that though. Apparently it has been run under IIS / PHP -

There's also a fairly unbiased comparison of wiki engines
Harry Fuecks Send private email
Wednesday, August 17, 2005
All very interesting, I have been searching for a collab-doc-wiki system to complement our fogbugz install. tried these...

flexwiki: removed (microsoft's: too basic)
perspective wiki: removed (don't remember)
mediawiki: removed (too complex)
openwiki: removed
phpwiki: removed (too complex)
moin-moin: removed
trac: removed (too much overlap with fogbugz)
instiki: not installed (not game enough to do the whole 'ruby on rails' thing)
tiddlywiki/gtd/tagglywiki: removed, but best gui
pmwiki: kept as personal wiki (uses php/flatfile?)
dasblog: kept as company intranet (uses aspnet/xml)

Yeh, technically dasblog is a blogging engine, but i'm using it differently.

Keep writing, i'm still reading!

Alan Send private email
Wednesday, August 17, 2005
I have never seen a wiki that actually works...

it is a good idea but in reality it never works..
PQ Send private email
Wednesday, August 17, 2005
I'll put in a vote for Confluence ( ).  It's a commercial product, which puts a lot of people off, but I've worked with a number of other wiki products and can confirm that you get what you pay for.  Confluence is a clear winner, in ease of use and robustness, over the vast majority of free wikis.

I'd say that MediaWiki is one of the few that match Confluence in terms of robustness.  I prefer Confluence because it's markup is simpler (the best of any wiki I've used) and it's features seemed a better fit for our requirements.  But I doubt that it has any built in support for multiple translations of pages.
John Rusk Send private email
Wednesday, August 17, 2005
MediaWiki has a very important advantage: it WORKS! It works out of the box, its ROBUST, its reliable. I've experimented with many other Wikis, but most of them were just pain in the ass. Yeah, there are some drawbacks (its not so easy to customize it), but having a good software that works is much much better than having a superb-fantastic-kickass software that does not.
Gabor Kulcsar Send private email
Wednesday, August 17, 2005
One other useful link:

Compares a few wiki markups
Harry Fuecks Send private email
Wednesday, August 17, 2005
I also recommend Confluence for its easy markup and ability to create links by surrounding text in square brackets:  [Internal Page Name].  The same way I convinced my employer to buy FogBugz, I convinced them to buy Confluence.

Confluence Notation Guide:

It's too bad you sold a book of your essays; you might have been able to convince them to give you a non-profit license otherwise...
Wednesday, August 17, 2005
I'd be more than happy to kick in a license for our ProjectForum wiki software - see

Images, files, authentication, versioning etc. all built in, without needing to install databases etc.
Mark Roseman Send private email
Wednesday, August 17, 2005
The Wiki I would recommend is MediaWiki by the Wiki Media Foundation
or WMF. There are always pros and cons in choosing a tool but my
personal choice is based on technical and organisational reasons.

To use any Wiki it must have at least the following characteristics
in no particular order:
    * Scalable. [1]
    * Well tested.
    * Multi platform. [2]
    * Built on stable stack, Apache, PHP & MySQL.
    * Multilingual. [3]
    * Usable documentation. [4]
    * Large user/developer base.
    * Ease of set-up, use and maintenance. [5]

The key organisational factor that makes the difference is the fact
WMF has a stable, over-arching organisation and leader.
    * Palatable license & philosophy. [6]
    * Overarching organisation.
    * Benevolent Dictator For Life, BDFL. [7]

MediaWiki is in for the long haul. The key reasons for my choice
    *Well used (tested) on lots of platforms
    *Easy to setup & maintain.
    *Strong leadership & Organisational umbrella guiding,
    development and use.

MediaWiki also allows for short URL s [8], Free links instead of
CamelCase. [9] The monitoring of Vandalism is possible through bots.

MediaWIki CANNOT do automatic language translation but supports multiple language additions. There is nothing stopping third parties adding their own translations of existing pages.

[0] `Wiki`, Wiki Wiki definition from the Wiki Wiki website by Ward
[Accessed August 17, 2005]

[1] `Wikipedia Traffic Ranking`, Shows Wikipedia daily traffic
information and Internet usage ranking. No# 56 most used Internet
site. :
[Accessed August 17, 2005]

[2] `Wikipedia Help Installation`, Shows different possible platforms to install:
[Accessed August 17, 2005]

[3] `Wikipedia Multilingualism`, Wikimedia support multi language
[Accessed August 17, 2005]

[4] `Wikipedia Documentation`, Documentation site:
[Accessed August 17, 2005]

[5] The set-up processes requires knowledge on setting up Apache,  PHP and MySQL on your current operating system. The additional set-up for Wikipedia (in my own experience) is trivial for installation, maintenance and upgrading.

[6] It is important to consider why the product has been created and what philosophy the BDFL has. Do you want to tie your use to a product that in 2 years time requires a change of license requiring payment for the latest version?

[7] `Benevolent Dictator for Life`, Wikipedia description of BDFL. An important indicator of project stability. Every (stable) major Open Source project has a BDFL. In the case of MediaWiki it is Jimbo Wales:
[Accessed August 17, 2005]

[8] `Using a very short URL`, Using shorter URL s to locate links. Beware this is an unsupported hack:
[Accessed August 17, 2005]

[9] `CamelCase and Wiki`, Describes how Mediawiki started with CamelCase and moved to Free Links:
[Accessed August 17, 2005]

[10] `Vandal tracking techniques`, Discusses how bots can be used to track automatically, changes made by vandals. Read the bottom title,`Home page changes every day are nice...`:
[Accessed August 17, 2005]
peter renshaw Send private email
Wednesday, August 17, 2005

  I would just use Media Wiki.  Its exactly the same software as used by wikipedia and is really simple to setup.  Took me about 20 minutes start to finish.

Ed Maas Send private email
Wednesday, August 17, 2005
Another suggestion, which is perhaps not an ideal candidate, because it's JSP based. But perhaps, besides the Java base, it's woth a thouhgt.

Alexander Deuscher
Wednesday, August 17, 2005
1. MediaWiki is the best, and contrary to your concern, is not difficult to set up.  No reason to use anything else.

2. Appoint language editors.  Give them admin privileges in the Wiki (so they can ban vandals in languages you don't speak etc.)

3. I heartily support the idea: that way, maybe I'll be able to contribute more than the two chapters I've translated from the UI book (into Hebrew).
Asaf Bartov Send private email
Wednesday, August 17, 2005
Why a Wiki at all?

Why not just carve a space on the web server, and open up a project with a hosted version of FogBugz to track versions of translations?

Is the point to use Wiki, or collaborate on translations?

Wednesday, August 17, 2005
simple question:

How does mediawiki (and other php based solutions) really support multilingual pages when php itself has poor unicode support?

I'd REALLY like to know the answer to this, from people who have actually been there and done it. It's one thing to be "international" and deal with English, French, Spanish etc which don't go far outside the latin1 charset, if at all. But what happens when someone tries to translate a page into Urdu, Arabic or Traditional Chinese? (Remember that they might be any one of a number of character input methods, and the only way that you have any hope of managing this is to say "unicode spoken here".)

So does it really work, out of the box, everywhere? Or will your user just get frustrated and go away?
Daniel McBrearty Send private email
Wednesday, August 17, 2005
My company uses MediaWiki for an internal wiki.  For the most part, we've been happy with it.  It's a little slow, but not so much to hinder adoption.  The only real complaint is that there's no good way to stage articles; in other words, there's no good way to save a draft article so that no one else but the author can read it.
Bill Smith Send private email
Wednesday, August 17, 2005
My company's been using for wiki software.  No markup language is required as it has a built-in rich text editor, can create links with or without CamelCase, can upload attachments including images, provides full user-level permissions as necessary, allows guest access, maintains a history of changes and allows diff-ing of changes, can be purchased as an appliance, and has a built-in scripting language and database that allows creation of forms and manipulation of data.  It's not free, but it's worth the cost.
Greg Kilwein Send private email
Wednesday, August 17, 2005
I have been using Instiki ( )

Ir runs on Ruby on Rails (soup du jour), and seems very smooth. I havn't had it scaling hard though....

Wednesday, August 17, 2005
One thing you might want to think about is WebDAV rather than a WIKI. IIS running on Win2K3 has support for DAV built in.

IIRC that allows you to provide security through the permissions of Active Directory and the 'V' stands for Versioning which will provide you with the ability to roll back changes.

Since you are already a Windows shop this could be an alternative that requires less configuration than installing an entirely new piece of software. I don't know how you would go about handling the look and feel of the site and what sort of templates are available but apparently it works (caveat - I've never used it myself).
Mr. Wobbet Send private email
Wednesday, August 17, 2005
I also recommend MediaWiki.

There's one big, big reason to pick MediaWiki: it's tried and tested with multiple languages.

MediaWiki is internationalized, supports input multiple languages, and offers autolinking to different translations of the same article, right in the side bar.

It is a little difficult to hack the templates, but it can be done. Setup is pretty easy -- mostly web-based, after you get the database installed.
Luke Francl
Wednesday, August 17, 2005
I've been running several instances of TikiWiki for a couple of years now. It may not be as easy to install as some of the other Wikis, but the featureset is more than sufficient compensation for it. Take a look, their website is and look at look&feel variations on some of the systems running it (
Michael Lyubinin Send private email
Wednesday, August 17, 2005
OK let me offer the Gordian Knot version of an answer:

Don't use a wiki. Use Plone.
Tim Keating Send private email
Wednesday, August 17, 2005
If you do use MediaWiki, a friend of mine has some great notes on installation and customizations, including how to make a special page for displaying your codebase changes (diffs):
Kevin Keck
Wednesday, August 17, 2005
Another vote for MediaWiki.  People like it so much that I wrote a converter to move a wiki from MoinMoin to MediaWiki.
Dan Littlejohn Send private email
Wednesday, August 17, 2005
Except one post (about pages being "vandalizated"), every post is about what Wiki is better/should be used.
My question is: does it have sense? And, will you have "certified" translators, or everybody can edit the translation pages?
A translation depends upon many factors (knowledge of english, of the subject, of the "target" language, etc.) and a lot of decisions are based on subjective criteria.
So while a "technical" wiki can be a good idea, since who posts or edits has tried himself the solution and know that is the right one (ok, there are exceptions to this, but happens rarely), a very good translation can be changed with a worse one just because the second editor thinks is better, and so could do the 3° occasional editor, and so on...
Marco Menardi Send private email
Wednesday, August 17, 2005
Dino Send private email
Wednesday, August 17, 2005
Hi, Joel. I translated some articles and a wiki seems complicated. Use something with a WYSIWYG editor and very easy to use.
Emerson Seiti Takahashi Send private email
Wednesday, August 17, 2005
what would be neat is if the system did an automatic machine translation of the article, notified a trusted set of translators who polished and refined it. Also allowed an easy way to see a reverse translation for Joel to make sure it wasn't a complete mangling of the original.
slava Send private email
Wednesday, August 17, 2005
MediaWiki...come on know it's the right choice.
Wednesday, August 17, 2005
A swiki (smalltalk wiki) stores the complete history of every page, so it's very easy to revert to an earlier version if you need to.

It's also easy to actually rename pages and link with any text you want.

Plus, it runs self-contained in smalltalk, so (I think) it doesn't matter what flavor of webserver it's sitting on.
Swiki User
Wednesday, August 17, 2005
Used both MediaWiki & FlexWiki. Ended up seting up FlexWiki for the company.

MediaWiki - tons of features, well developled, easy to setup. FlexWiki is missing at least 30% if not more of MediaWiki features (image uploads, section edits, etc)

Yet FlexWiki end up as winner. Why? Because its *sexy*. The feel of using FlexWiki is completely different. Using Flex is like playing the game, its just *fun*. Topics show cute mouseover summaries, topic name is instant-jump bar.small pull-out wiki syntax helper in editor is like cup of fresh water in desert for any wiki newcomer. namespace layout is (surpise, surprise)...just another topic in Flex which you can not just edit, yet also script with WikiTalk. we immidately scripted it and had some nifty features on side bars - like real-time contributions by author quick nav tables, etc.

In short usual story. Cool usability wins the day over raw power of engines with cardboard UI.
MaxS Send private email
Wednesday, August 17, 2005
Joel, I have a company called CustomerVision and we have developed a wiki product with a number of features typically associated with a web content management system, so it is very good for easily publishing a lot of articles. For example, it has an option for category based navigation like you find on a news site. Most of our current customers are large companies (like Wells Fargo, Heart and ING) use the product in a secure intranet environment but the latest version works fine for web or intranet. We have a hosted model like Jot or Socialtext so you don't need to install anything. We are interested in getting more non-intranet installations so we would be glad to let you use the software for free. If this is of interest let me know and I would be glad to give you a demo or just get you setup with an account that you could try. You can check out a sandbox site at . This will give you some idea of the functionality but it doesn't provide a great idea of what a fully populated site looks like.
Brian Keairns Send private email
Wednesday, August 17, 2005

One of the easiest wiki to install, configure and custumize is, I think, PmWiki

You don't need database, just php.

My website is one example of what you can do with pmwiki (lot of more example here: )

You can see what this wiki provide:
Vianney Lecroart Send private email
Thursday, August 18, 2005
Yes, the public wiki will be a good idea. Right after you have published my translation of "Hitting the High Notes", a girl have got another translation of that article of her own and you know what? Her translation is better.

So I am for the wiki and for the replacement of my translation with hers..
Egor Egorov Send private email
Thursday, August 18, 2005
Use MediaWiki. I'm no Linux expert and it took me about 20 minutes to install and configure it
David Hayes Send private email
Thursday, August 18, 2005
I set MediaWiki up as knowledge management tool for two software dev teams in my company. 

I can definately confirm is easy to install.  I'm a complete noob to Linux and I still managed to set it up in half an hour.  Any experienced *nix type could do it in their sleep.

I picked MeidaWiki because
a) the user base indicated that it must be pretty stable
b) it didn't require camel case
c) it had all the features I was looking for but was not loaded down with feature bloat.
Brian Surratt Send private email
Thursday, August 18, 2005
Yet another wiki:
 (both english and russian pages).

 1. Very easy to install (PHP + Mysql).
 2. Very easy to upgrade (all is automated - all databse and config conversions etc).
 3. Multilanguage support - after registration you could select your language of interface (and charset of page). There is support for keywords (links to pages) in every language supported (they are transliterated to english).
 4. You could set special permission to edit page but enable "comments" for all people to comment the page (post corrections and suggestions).

Nekto2 Send private email
Thursday, August 18, 2005
Although you said you didn't want a CamelCase wiki, I thought I'd pitch in a comment that might interest you.

For our software engineering capstone project, we created an Eclipse plugin which is a graphical editor for the Use Case Map notation (the editor will be published shortly at

In any case, during our whole project, we used TWiki to manage our project's requirements. Using TWiki forms and queries, we setup a simple environment where all involved parties could share in defining the requirements. When a requirement was found to be unclear during development, we started a discussion on that requirement's TWiki page.

We created all our reports directly on the wiki so everyone could participate in writing them, instead of circulating Microsoft Word documents all over the place.

Furthermore, we installed a few TWiki plugins that allowed us to link directly to our BugZilla (using %BUG{NUMBER}% and the like) so discussions could be linked to our bug tracking system. Another plugin breaks up the display of CamelCase words (to Camel Case) so that help readability in our reports. Other plugins exist to add drawings on page and the like.

We found TWiki to be very powerful while remaining extremely simple to use. We didn't impose a severe project management structure on our team; TWiki helped us increase our synergy, without the overhead of learning (and purchasing) new project-management-specific tools. The application has worked great for us and I was wondering what you use internally for such purposes?
Jason Kealey Send private email
Thursday, August 18, 2005
(Obviously apart from FogBUGZ :) )
Jason Kealey Send private email
Thursday, August 18, 2005
Joel, if you want the wiki that suits you best there is no better method then to look around and try out some (and, most likely, to change some things yourself). You can find some comparisons of wiki-engines, for example here:

I recomment wikkawiki ( you can insert stuff like freemind-maps and rss-feeds from other pages and we use a good code-highlighter [geshi]) -- Disclaimer: I am involved in the development.
Nils Lindenberg Send private email
Thursday, August 18, 2005
I know that everyone has an opinion on this. Having recently struggled with this, I've settled on FlexWiki.

It's easy, I've re-organized it about 5 times, and it just works! It does link to topics using CamelCase by default, but there is easy syntax to do otherwise:
  "Joel on Software":

In fact, Microsoft uses this tool for a boatload of internal wikis and some external ones such as their Channel 9 site ( )

It does help to know ASP.NET and how those sites work :-)
Peter Christopher Send private email
Thursday, August 18, 2005
subversion/trac has a wiki. it's not amazing, less complete than twiki, but easy to get started.
Paul Mansfield
Friday, August 19, 2005
if not a wiki, how about Silva?


Paul Mansfield
Friday, August 19, 2005
Another vote for PmWiki.

* It can't get easier to setup. Unzip and go.
* You can fiddle around with the looks through an ordinary CSS file. Took me two hours to match my site, including correcting some of the swedish language files.
* Nice and stable, have not managed to mess it up yet.
* Maintains full history.
* Has got various options for organization (easy to set up sequences and sub-sections)
* Integrates nicely with various security variants
* Has an editor with buttons for inserting wiki codes
* Can be set to only allow explicit links, using [[Topic]] syntax or [[Topic|cleartext]] syntax.
* Has support for defines, so you can easily make a more advanced and standardised layout. For instance, %CodeSnippet may set a whole bunch of font, color and other settings.
* Has support for tables. Many wikis fall short on that one.
* Decent search facilities.
* Has separate layout for printing
* Has tools for administrative tasks such as finding orphande topics.
* Requires nothing but a PHP-capable webserver and PHP.
* The code is small enough to be changed easily if there are something you don't like.

In my opinion, it is a neat, streamlined package, that balances perfectly on the fine line between features and bloating. I run it both on a public website (with another one planned) and a private wiki for my own notes.

I recommend it unreservedly!
Anders Troberg Send private email
Friday, August 19, 2005
I add to the list of JSPWiki ( ).  It is a very fast, easy to install, easy to use Wiki.  I've been using it for the last few years for my personal site and have installed over a dozen instances at customer sites I've worked at. 

There is a constant stream of new features being added.  It has the ability to act as a blog, so people could comment on the articles. 

Highly recommended.
Foster Schucker Send private email
Friday, August 19, 2005
Another java wiki is snipsnap ( looks good
Kris Kopera Send private email
Friday, August 19, 2005
I would really recommend you take a look at . I chose it for a project after considering quite a few wikis. It Java based and is very easy to install; it is fast, supports plugins, and it's easy to learn and use.
Hadi Asghari Send private email
Friday, August 19, 2005
Try to use Mambo( It's quite a good CMS. I have been using it as Knowledge DataBase in our firm.

Hope it helps.
Brdgs, MK

Friday, August 19, 2005
I'd suggest MediaWiki, myself. I saw someone claim wikis don't make it easy to revert to older versions; I know mediaWiki makes it *very* easy to revert to any version you want. And, of course, most people know it, and it's *easy* to set up.

I'd also suggest populating your wiki with machine-translations into the various languages you want documentation in, no matter which wiki style you use. Then the task becomes one of sanity checking and editing moreso than the actual translation.
Michael "Sotek" Ralston Send private email
Friday, August 19, 2005
+1 DokuWiki

All our company runs is IIS and it works perfectly except for LDAP authentication with a Win2K domain pulling group membership.

PHP EasyWindows Installer will get you running PHP on IIS in about 30 seconds.

Friday, August 19, 2005
I hope I'm not late! Please stay away from MediaWiki. It's for geeks :-P

It's not all that difficult to setup, but to customize?

Why not one of these:
Ivan Vega Send private email
Friday, August 19, 2005
It'd be nice. That way, we'd get to comment on articles too. We could use the bottom of the Wiki for reader comments. To fix periodic bugs in articles and shiat.

Friday, August 19, 2005
I like MediaWiki's features and support, but it's a friggin' bear on the server hardware. I mean, it's Just Not Fast, and unless you care to throw the hardware and set up the software (wikipedia uses the Squid cache so most hits don't touch MediaWiki code directly), expect it to drink CPU.
Paul Kroll Send private email
Saturday, August 20, 2005
Linking to translations in MediaWiki is not automatic, unless you count a list of translations in the markup "automatic".

I think having a form on the JoS site to submit translations may be better than a full-blown wiki for Joel's needs. After a translation is submitted, it could be posted to a preliminary area, and later posted to the translations section of JoS. Heck, maybe a forum software would suit Joel's needs better.
Joseph S. Huang
Saturday, August 20, 2005
my preferences: --  really good markup and features (btw the have the wonderful - the same engine+blogs+facete classification) -- Python, easy customization, access control and soo on -- its wikipedia!
Max Belugin Send private email
Monday, August 22, 2005
Out of curiosity, I tried setting up MediaWiki to compare it to FlexWiki. Installation was a breeze, and I was shocked at how small the install file was (2mb how?!?!).

It was super easy to install on XP.  I already had PHP and MYSQL installed.  Their docs say that it's not recommended, but their installer rocks.  It does everything for you.

I had to make a simple code tweak because IIS doesn't support one of the standard server variables, but it's just search and replace.

FlexWiki and MediaWiki are both pretty awesome.  I'm considering switching to MediaWiki because of the pile of features such as file upload and all the other cool stuff I've seen on Wikipedia.
SuperJason Send private email
Monday, August 22, 2005
Why not Windows SharePoint Services?  It's essentially free, isn't it?  Don't flame me for suggesting an MS tool :-)
Jim Parker Send private email
Monday, August 29, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz