[Koha] wiki.koha-community.org

[MJ Ray]

Thomas Dukleth wrote:
> On Thu, April 15, 2010 10:20, MJ Ray wrote:
> > Is it proper reasoning if it can't be expressed concisely? ;-)
> 
> My personal preference is to show reasons, evidence which underlies
> reasons, and relevant background to enable people to have an opportunity
> to properly understand the strength or mistakes of my reasoning and offer
> their own alternatives with common points of reference.  There are some
> irreducible complexities in the world which deserve due consideration.  I
> always try to avoid easily formed oversimplification.  However, I am
> mindful of the helpful preference for concise expression.  I often lack
> the time to prepare work which is both thorough and concise.

At the moment, it feels to me that this discussion is falling between
two stools:
 - it's too long/complex for most of the community to participate;
 - it contains unreferenced incorrect/incomplete claims (English/Spanish
below, for example).

Given the choice, I'd go for quick non-repeated points with references
in a short discussive post, then summarise comprehensively before
checking for consensus if needed.

> [...]  Perhaps the reference is to coordinated wiki farms
> or families which are used by the Mediawiki foundation for multilingual
> wikis, http://www.mediawiki.org/wiki/Manual:Wiki_family .

Sorry, WikiFarmer is a less offensive-to-some name for
http://c2.com/cgi/wiki?WikiFaeries
but I didn't realise it wasn't known widely.

> > but I don't believe that mediawiki is the best (or even a good) solution.
> 
> I gave some reasons in my previous message about why I think that
> MediaWiki is a good choice relative to various problems which I found in
> my extensive experience working with DokuWiki,
> http://old.nabble.com/Re%3A-wiki.koha-community.org-p27860816.html .  One
> of my most significant findings is that plugins which help resolve
> problems that I have found with DokuWiki resolve those problems by making
> DokuWiki more like MediaWiki.

I replied in
http://old.nabble.com/Re%3A-wiki.koha-community.org-p28253661.html to
give reasons why those findings looked to me to contain confusion
about how other wikis do most of those tasks.  I suggest this is due to
over-exposure to mediawiki and lack of familiarity with quicker wikis.

We can re-cite previous messages from this thread but it doesn't help
make progress.  I'm trimming a lot because the email looked like
it was repeating the same few reasons many time.

> My appeal to popularity in the reasons which I gave favouring MediaWiki in
> my recent previous message merely identified the high demand from users
> and that the large MediaWiki development community which followed from the
> popularity.  Those two consequences of popularity should help to ensure
> that MediaWiki would continue to be an especially scalable and featureful
> wiki into the future. [...]

Why?  As someone who used to study time series statistics, I've seen
many times when the past doesn't help predict the future.  The
conditions around the project don't suggest the stability for such
predictions to be useful, such as the continuing appeal for donations
by the project host and its strategic plan looking fairly short-term.

Why would those features be right for us?  MediaWiki development
appears to be dominated by encyclopaedias, which have rather different
aims to project development documentation.  Are there things on
http://www.mediawiki.org/wiki/MediaWiki_roadmap
which we actually need?

Need we even care about upstream development much if the features we
need now are already present and new ones are easy for us to develop?

Wikis should be quick.  It's what wiki means, after all.  MediaWiki
complicates a simple idea and tries to bend it into a CMS.  If we want
a fuller CMS, the community knows other ones better already (Kete,
drupal, django-blocks).

> [...] Did you mean to refer to anything else, aside from
> administrative complexity, in terms of configuration problems?

I don't remember if there was anything else after this time, but
administrative complexity was the main concern.

> We do not need to implement captcha images which lack an audio alternative
> in MediaWiki.  Obviously, the fact that no one has written the code for an
> audio alternative for the MediaWiki captcha extension is unfortunate but
> we can avoid the problem altogether.

Audio alternatives are not a solution: a higher proportion (40% IIRC)
fail typical web hearing tests than eyetests, so there is a
significant overlap who will fail both.

Please do not call eyetests and hearing tests CAPTCHA.  The "CHA" bit
stands for "tell Computers and Humans Apart" and ability tests cannot
do that, because not all humans have those abilities.

> Do you know of any other accessibility issues for MediaWiki and are they
> any worse than accessibility problems of DokuWiki?

If we can agree that the default stylesheets for both are poor and would
need replacement, then it's mainly the eyetest.

> Serious attention
> seems to be given to accessibility for MediaWiki,
> http://blind.wikia.com/wiki/Mediawiki_and_Accessibility [...]

Is that serious attention, last modified over a year ago?

> 5.4.  WIKI DEFINITION.
> 
> > and that it arguably is
> > not even a wiki.
> 
> How is MediaWiki not a wiki?  Do you mean that MediaWiki does not support
> camel case links without an extension?

It's not quick and uses something much more complex than the
TextFormattingRules.

> Camel case wiki links can be activated in MediaWiki if we need them.  I do
> not find it helpful that referring to BibLibre, BnF, ByWater, ePUB, or
> LibLime in DokuWiki produces perhaps unintended wiki links automatically
> but not the use of other names not containing Camel case. [...]

Shouldn't the wiki have pages defining those terms, even if just as a
quick pointer?  Accidental links aren't necessarily bad.

> 5.5.  MULTILINGUAL IMPLEMENTATION.
> 
> > Is "a good multi-lingual implementation of MediaWiki" even possible?
> > If so, why doesn't Wikipedia use one?  Wikipedia's current
> > wiki-per-language implementation is very frustrating to use.  Have you
> > tried it?  If you switch language, you can go two clicks on and then
> > not have a way back to the previous language at all, except by going
> > back.
> 
> We can have persistent navigation links in addition to page content
> specific links in a MediaWiki implementation.  [...]

If persistent navigation links would simply link to the top pages of
those other languages, then that seems less helpful than going back.

So I am really doubtful that DNS is better than the Accept-Language
HTTP request header, possibly overridden by URL path or cookie.

As I understand it, using DNS means that they are distinct wikis,
increasing the wiki administration and management problems by some
multiple of the number of languages.

> > Also, if some page does not exist in a language, it often isn't
> > linked on that language's subdomain, so you probably won't know it
> > exists in *any* language.
> 
> Searching can be configured to function globally for all MediaWiki wikis
> in a wiki family which would consequently work across different languages.

How would a reader know in what language to enter the search term?

> > For projects like Koha which are actually
> > multilingual, where some things might exist in French or Spanish
> > before English, this is bad.
> 
> We should encourage users to create at least an empty page in the English
> wiki for any content which they are creating in a localised wiki alone.  A
> bot might be used to correct the problem.
> 
> Much MediaWiki administration is accomplished using bots.  I created a
> page at mediawiki.org correcting for some deficiency in identifying
> helpful bots, http://meta.wikimedia.org/wiki/Lists_of_bots .

Most bots seem like a crutch to overcome poor design decisions.  Poor
internationalisation is one such decision.

How many of the 1100 bots active on wikipedia would we need?
http://en.wikipedia.org/wiki/Category:Wikipedia_bots_by_name

Also, historically, the project has struggled to provide stable hosting
for simple IRC bots.  How confident are we that we can host and manage
the subset of bots that we need?

> > Not even a wiki: compare
> > http://www.c2.com/cgi/wiki?TextFormattingRules
> > http://www.mediawiki.org/wiki/Help:Formatting
> >
> > Bold, italics and rules are the same, but most of the rest is often
> > wildly different and usually mediawiki gets much more complex.
> > Mediawiki often looks better, but the cost is much ease of editing.
> 
> People are not required to use the full expressive complexity of a
> particular syntax.  However, I recognise that inconsistencies in MediaWiki
> syntax for links are unfortunate.  Every syntax has some oddities which
> are a point of difficulty.  DokuWiki syntax for namespace creation is a
> difficulty in DokuWiki.
> 
> Here is a point where popularity ought to matter because MediaWiki syntax
> is most familiar to the largest numbers of people.  Spanish is simpler and
> easier to use than English but English is understood by more people in
> common and thus more suitable as a global common communication language.

As you might expect from a multi-language user, I disagree with that
conclusion about suitability.  There's a lot of other factors besides
popularity to consider when choosing a language.

Moreover, English may be understood by more people than Spanish, but
that's misleading by omission: Ethnologue.org puts the number of
native Chinese [zho] speakers higher than the highest *combined*
native+second-language English speakers estimate I've seen (1.2bn v
0.48bn from the rather controversial
http://www.andaman.org/BOOK/reprints/weber/rep-weber.htm ) so that
argument logically leads to switching the wiki to primarily Chinese.

Of course, that would ignore our project history and probable future,
in a similar way to switching to MediaWiki syntax.

> I note in that reference that the advantage which DokuWiki once had over a
> syntax issue which is of importance to me is now an advantage for
> MediaWiki.  DokuWiki provides for 5 levels of section headings while
> MediaWiki now provides for 6.  As I had stated in my previous message I
> may be the only one who has created content in the Koha wiki which used 5
> levels of section headings.

I hate to criticise someone who's done so much good documenting things,
but I suggest section headings 5-levels deep isn't good wiki style.
At work, we rarely go beyond 3 deep before splitting the topic.

> [...]
> > Does everyone realise that most wikis can do categories, through
> > backlinks of Category pages?
> >
> > See for example http://www.c2.com/cgi/wiki?CategoryCategory
> 
> Every wiki certainly has some means for creating categories.  The issue
> which I treated at length in my previous message is the range of features
> which help the user make use of categories to find content.  Please see my
> previous message for that discussion,
> http://old.nabble.com/Re%3A-wiki.koha-community.org-p27860816.html .

I replied in
http://old.nabble.com/Re%3A-wiki.koha-community.org-p28253661.html
that no-one has really tried to add this to wiki.koha.org yet.  I
suggest it's an organisational limitation and not a feature one.

> > It's not something anyone has really tried to add to wiki.koha.org
> > yet, but it's there and ready to use if anyone wants to start linking
> > pages to Category pages.
> 
> As I have documented in my previous post their are means of implementing
> categories in DokuWiki particularly with some plugins.  However, the
> support for the use of categories in MediaWiki particularly with a larger
> set of extensions seems much better to me for serving the purpose of
> enabling users to find relevant content.

The search is the way most people find things on wikipedia.  It even
out-ranks the front page.  Even though our community will probably use
classifications more than most, plugin-based category support is
over-complicating a lightweight core feature.  Can we try implementing
categories in the simple WikiWay before playing with plugins, templates
and other similar complications?

> 6.  TAKING DECISIONS.
> 
> >  No need to junk the wiki software, but maybe
> > we can do better than dokuwiki.  I really don't see mediawiki as a
> > step forwards, though.  Is there still time to reconsider?
> 
> Firstly, no decision has clearly been taken other than the start of a
> mostly yet unconfigured MediaWiki implementation provided by Equinox.
[...]
> Do you object to testing in use as Galen had suggested?  [...]

Well, testing in use sounds like a popularity contest by another name.
I predict at least two large disturbances in this choice:
  1. familiarity of mediawiki sites;
  2. the TEAM effect, where many vote for the glossier-looking option
and few have to work with it (TEAM = "Toll! Ein anderer macht's", or
"great! Someone else will do it").

How can we structure the choice to minimise the effects of those?

Thanks,
-- 
MJ Ray (slef)  Webmaster and LMS developer at     | software
www.software.coop http://mjr.towers.org.uk        |  .... co
IMO only: see http://mjr.towers.org.uk/email.html |  .... op