support mediawiki format completely and converge/eliminate the existing tracWiki format

[anonymous]

There are compelling reasons to support mediawiki format completely in the core trac release.

1. jamwiki is cloning mediawiki in Java and keeping the format identical so Java-based projects can easily integrate a full wiki.
2. drupal_wiki is likewise supporting mediawiki format as its native format
3. mediawiki is very widely used in intranets already including very large ones like the US inteligence services' "Intellipedia"
4. mediawiki is also widely used for documentation and requirements engineering by open source and share-alike (including free software and open content) projects - most of the target market for trac has to support mediawiki anyway, and in some cases has a strong motive to update large public wikis running on mediawiki
5. of hundreds of millions of page reads from wikis every year, the overwhelming majority of those are from wikis using mediawiki format. The public interest in supporting, teaching and implementing this format is now immense and unstoppable, even if a markedly "better" wiki format existed, it would not overcome this data compatibility problem.
6. Most importantly, almost all technical and requirements domain concepts that might need to be referred in specifications already have names in most widely used languages thanks to Wikipedia. Working out the most neutral and least controversial names for tens of thousands of scientific, technological, business and other concepts has been the greatest contribution of the Wikipedia project. Since those names are expressed in the characters allowed in mediawiki names, with many conventions growing out of Wikipedia usage, any deviation (any more or less permissive use of characters) would "break" the character set and force "translation" of names of concepts to determine if the concept existed in the Wikipedia namespace (or "GFDL corpus namespace" to be legally more exact as all Wikipedia content is under GFDL and other mediawikis copy the names under this license).

Accordingly, the benefits of keeping trac internal data and user's internal documentation in mediawiki format are profound:

6. any concept whatsoever that is named in a document can be quickly checked to see if it exists in Wikipedia or a list of other public wikis, and the option to link it added
7. statistically improbable phrases can be related to more standard phrases by relatively simple programming/searching methods, e.g. consulting Amazon lists of keywords attached to books, checking for matches with text of Wikipedia articles
8. any page managed by Trac can be instantly moved to, or can instantly incorporate updates from, or possibly embed or be embedded in, any other page in a large public wiki or mediawiki- or drupal- or jamwiki- based intranet
9. TracWiki could become the Python equivalent of jamwiki (Java) and possibly be included in other applications as a module as is intended for jamwiki; This would better distribute the maintenance effort and spread trac
10. mediawiki extensions would be encouraged to integrate trac so that, for instance, bugs in mediawiki-based services would be able to contain trac links directly in talk pages and edit summaries.
11. anonymous trolls are more likely to complain about errors seen in trac, as all anonymous trolls already know mediawiki format so they can troll Wikipedia
12. such trolls will no longer appear to write long whiny tickets like this. These advantages will get more significant, not less, over time, as the number of trolls in the world increases (we may be in the Troll Age).

To converge/eliminate the existing tracWiki format would be relatively simple as most of mediawiki's text conventions (regarding italics, boldface and headings) are supported already. The link format, relying on double square brackets, conflicts with the existing tracWiki macro format, but this is easily resolved by a method similar to methodNotFound in Smalltalk, etc.: if a local macro by that name does not exist, the behaviour defaults to an open link. This is then easy to replace with another macro that can default to find (and link) the appropriate article (via the methods listed) in a more public wiki, or a cascade of nested wikis of decreasing specificity. This is similar to the technique wikinfo.org already uses to embed Wikipedia articles when wikinfo itself has no article on that topic.

Discouraging WikiWords is of high priority as they encourage bad English and make sentences containing links unreadable and confusing to technical people (exactly why mediawiki abandoned them).

[Emmanuel Blot]

Oh my… what about some line breaks?

[Noah Kantrowitz]

-∞

[Christian Boos]

Re-formatting … well, I doubt even MediaWiki would have liked the original format ;-)

I also renumbered the items for easy referencing.