On 12/29/10 3:21 AM, MZMcBride wrote:
David Gerard wrote:
On 29 December 2010 08:24, MZMcBridez@mzmcbride.com wrote:
To me (and others), that leaves the question of what would happen if you wrote some software that was actually built for making an encyclopedia, rather than the jack of all trades product that MediaWiki is.
MediaWiki is precisely that software. And there's any number of specialist wikis using it that are basically Wikipedia in a specialist area.
No, I don't think MediaWiki is precisely that software. MediaWiki is a wiki engine that can be used for a variety of purposes. It may have started out as a tool to make an encyclopedia, but very shortly after its mission drifted.
I agree. If MediaWiki is software for creating an encyclopedia then why are the tools for creating references and footnotes optional extras? It's rather difficult to set up MediaWiki so that it works in a manner similar to Wikipedia or Wikimedia Commons (and I know this from experience).
Scale matters too. Right now, any new feature for MediaWiki has to be considered in the light of some tiny organization running it on an aging Windows PC, as well as running a top ten website. It's amazing that MediaWiki has managed to bridge this gap at all, but it's come at a noticeable cost.
Question: assuming that our primary interest is creating software for Wikipedia and similar WMF projects, do we actually get anything from the Windows PC intranet users that offsets the cost of keeping MediaWiki friendly to both environments? In other words, do we get contributions from them that help us do Wikipedia et al,?
MW2.0 would use actual input forms for data, instead of the completely hackish hellhole that is "[[Category:]]" and "{{Infobox |param}}". MW2.0 would standardize and normalize template parameters to something more sane and would allow categories to be added, removed, and moved without divine intervention (and a working knowledge of Python). MW2.0 would have the ability to edit pages without knowing an esoteric, confusing, and non-standardized markup.
+1
I think it is vital to keep templates -- it's a whole new layer of creativity and MediaWiki's shown that many powerful features can come about that way. That said, we also want a template to have some guaranteee of sane inputs and outputs, and maybe a template could also suggest how its data should be indexed in search engines or for internal search, or how to create a friendly GUI interface. Perhaps that would be impossible for all cases, but if XML made it easy in 95% of cases, I'd take that tradeoff.
As a programmer I am somewhat dismayed at the atrocities that have been perpetrated with MediaWiki. (Wikimedia's hacking language variants to show licensing options is my favorite). As someone who believes that given freedom, users will create amazing things, I'm blown away by the creativity. I think those show the need for a *more* powerful template system, that is hopefully easier to use.
Maybe this is anathema here, but XML seems like a logical choice to me. While inefficient to type in raw code, it is widely understood, and we can use existing tools to make WYSIWYG editors easily. So perhaps an infobox could be edited with a sort of form that was autogenerated from some metadata that described the possible contents of an infobox.
Also, XML can encapsulate data and even other templates to an infinite degree. A few months ago somebody asked how they could implement a third layer of "quoting" in the geocoding template syntax and it just seemed to me like this problem shouldn't have to exist.