MediaWiki-style alternative wiki syntax

[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:

7. 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
8. 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
9. 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
10. 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
11. 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.
12. 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
13. 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.

[Christian Boos]

No doubt about points 1. to 5, mediawiki is becoming a kind of standard… It would definitely be interesting to support more than one wiki format. As a matter of fact, one can already write pages in WikiRestructuredText.

With future versions of the WikiEngine, it should be possible to write a different Wiki parser and "plug" that one into Trac, either as the default syntax or as an additional one.

Once such a plugin exist, there could be some discussion taking place if we should ship Trac core with this alternate syntax (or less likely, replace the simpler MoinMoin inspired one by a Mediawiki compatible one), but not before…

That being said, there are a few tickets opened that aim to integrate some of the good things from Mediawiki, see search:?q=mediawiki&ticket=on

See also WikiCreole for efforts on getting the TracWiki syntax more "standard".

Then for points 6. and 7., referencing pages into other wikis (like Wikipedia) can already be done using explicit InterWiki links (e.g. ​MediaWiki:InterWiki). Proposing a link to another Wiki on the new wiki page, i.e. when you follow a link to a non-existing page is an interesting idea, but is probably also best done with a plugin.

I'm pretty skeptical about points 10. to 12…

Finally, CamelCase haters (hi Pierre!) are already taken into account, as one can create any kind of WikiPageNames, and it's possible to turn off the generation of new page links when the wiki text contains a CamelCase word for which there's no corresponding wiki page (see TracIni#wiki-section).

[Christian Boos]

(the InterWiki example should have been: ​Wikipedia:InterWiki)

[anonymous]

This reduces to three questions:

1. is there really any purpose to separating a parser if you're only going to end up supporting one format?

2. if more than one format is supported, should mediawiki-style naming and linking be the default, that is, what ordinary users expect to use, with the older syntax available only as an option for sophisticated users?

3. is it actually worthwhile to support any formats other than the defaults, given that they encourage bad habits and splinter the development/support/data ?

Sadly, "WikiCreole" is worthless as it breaks mediawiki's existing format and thus ignores all of points 1. to 6. - by no means should TracWiki adopt it. It's sad as it would have been relatively simple not to do that. However, the WikiCreole effort does not accept any outside input, or rather, it pretends to but in fact has already made a lot of bad design decisions - and is wholly incognizant of the data compatibility problem. WikiCreole is definitely a dead end. The only thing it proposes doing that's worthwhile is allowing "== section" titles without a closing "==", etc., but this implies line-breaks acquiring even more meaning.

Interwiki doesn't go nearly as far as Wikinfo (using getwiki) which imports all of a vast database of pages and treats them, for all intents and purposes, as native pages from the user's point of view. Tikiwiki had similar and even more flexible features.

Obviously this exchange is itself an example of points 10 to 12… but more importantly it's hard to ignore points 7 and 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

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

It's doubtful either could be achieved unless Trac abandons the boat anchors of WikiWords, MoinMoin, WikiCreole and "open" parsing formats. It's hard enough to track even a slowly moving target like the mediawiki format.

Action items:

• start a new effort to extend mediawiki format without breaking it, to replace the failed WikiCreole

• convene a session of Python developers to discuss the need for an inbuilt mediawiki-compliant engine like jamwiki for Java

• treat any defaults other than mediawiki's as bugs, that is, deviations from its format, namespace and linking conventions as defects, not as personal choice

[Christian Boos]

Ilias? Is that you?

More seriously, it's a bit sad that you're ruining what could have otherwise been a good idea with such a grandiloquent tone ("convene a session of Python developers …" really?).

I see nothing more to add to what I've already said in comment:4, please re-read it. In short: first the wiki parsing overhaul, second (and maybe, like if someone has the time & energy to contribute quality code) a mediaWiki parser, third (and it might be, like if there's tremendous pressure from our user base) make that the default. At best count, a Trac release for each "action item".

[anonymous]

"Tone" isn't a good reason to get rid of a "good idea". If it's really a good idea, overlook the tone and look seriously at the merits of the proposal. Also, speculating on the identity of any person who prefers to remain aonymous and isn't lying or something is in very bad taste.

WikiCreole and WikiWords are dead. Jamwiki and drupal_wiki have already adopted the mediawiki format. This proposal needs to be examined on its merits, not based on internal project politics.

If it really offends you, open a new ticket listing the justification points you agree with.

[Christian Boos]

After the WikiEngine refactoring, it should eventually be possible to write alternate Wiki syntaxes, the DokuWiki one and MediaWiki one would probably be the most interesting ones.

[Khopesh]

Possibly helpful links for python-based MediaWiki parsers:

• ​mwlib
• ​py-wikimarkup
• See also ​MediaWiki:Alternative parsers

Also, isn't this an enhancement request rather than a defect?

Trac's WikiFormatting is one of a small list of things stopping my company from using Trac.

[Christian Boos]

Replying to Khopesh:

Possibly helpful links for python-based MediaWiki parsers:

Thanks!

Also, isn't this an enhancement request rather than a defect?

Sure.

Trac's WikiFormatting is one of a small list of things stopping my company from using Trac.

I guess it's because you Trac WikiFormatting isn't considered to be "standard". So what would be acceptable standard? Only MediaWiki or wouldn't WikiCreole also do?

Also, what are the remaining items on your small list? :-)

[dr2chase@…]

If I may vote, I think that MediaWiki is winning mindshare, and I think it would be a great idea for Trac to support it. Transition might be a problem, but I think we need to do it.

[dr2chase@…]

Replying to dr2chase@…:

If I may vote, I think that MediaWiki is winning mindshare, …

Or perhaps, WikiCreole. The guy (Guy Steele) who is designing the doc comments for Fortress chose WikiCreole. I'll check back with him to get his reasons for preferring WikiCreole to MediaWiki, but I'd call this a strong vote for WikiCreole.

But, whatever else, I think it is a mistake to remain gratuitously different.

[Christian Boos]

Replying to dr2chase@…:

But, whatever else, I think it is a mistake to remain gratuitously different.

We're not "gratuitously" different, Trac's wiki syntax started very similar to that of MoinMoin, which was and still is a widely used wiki. But MoinMoin evolved in direction of WikiCreole (see the current ​MoinMoin:HelpOnMoinWikiSyntax, in particular the link syntax), so should Trac.

[anatoly techtonik <techtonik@…>]

What is wrong with Trac link syntax? ​Google Code uses it as well. MediaWiki and WikiCreole link syntax is ugly and requires to type more.

It WikiCreole link standard seems to be blindly chosen after MediaWiki without any solid reasoning. Why MoinMoin switched to a new syntax is also unknown. Perhaps they've looked at WikiCreole.

[Christian Boos]

Milestone 2.0 deleted

[get]

Replying to cboos:

Replying to Khopesh:

Possibly helpful links for python-based MediaWiki parsers:

Thanks!

Also, isn't this an enhancement request rather than a defect?

Sure.

Trac's WikiFormatting is one of a small list of things stopping my company from using Trac.

I guess it's because you Trac WikiFormatting isn't considered to be "standard". So what would be acceptable standard? Only MediaWiki or wouldn't WikiCreole also do?

We have started workin on our company with trac and now we wont change back, this is the most powerfull suite ever.

Also, what are the remaining items on your small list? :-)

[shesek]

I just uploaded a plugin to add support for Underscore_Wiki_Pages, you might find this interesting. ​http://trac-hacks.org/wiki/UnderscoreWikiPlugin

[Christian Boos]

Replying to anonymous:

No matter how tough your situation is, you never risk your retirement savings to get yourself out of a tough financial situation. There are always other ways to get your finances in order. If you mess with the future to make your current situation better, it only leads to trouble down the road. ​Hotels.com Coupon Code

Human verified via CAPTCHA ???

Seriously, is there someone with a brain behind the above comment?