On 12/29/10 3:21 AM, MZMcBride wrote:
> David Gerard wrote:
>> On 29 December 2010 08:24, MZMcBride<[email protected]> 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.
--
Neil Kandalgaonkar ( <[email protected]>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
