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