[Koha] wiki.koha-community.org

Thu May 6 11:01:56 NZST 2010

I'm bumping this back up since it came up in today's meeting and I had
to leave.  The new wiki is ready for content and I have been adding
some (as have others).  I know that using namespaces seems important,
but it's just too time consuming and too hard for people (as we can
see by the mess that was the old wiki).  I recommend that we create
subdomains for each different language and let people write content in
their own languages.  Page names
(http://wiki.koha-community.org/wiki/index.php/Special:AllPages)
should be clear and easy to understand and ease to find via search.
To keep things organized I have created a few categories and we can
all keep adding categories
(http://wiki.koha-community.org/wiki/index.php/Special:Categories) as
we think of them.  This way we can browse the wiki if we want.

The most important thing right now is making the move to the new wiki
and this is the quickest way to do that.

Thanks,
Nicole

On Thu, Apr 22, 2010 at 5:13 PM, Thomas Dukleth <kohalist at agogme.com> wrote:
> Rely inline:
>
>
> On Thu, April 15, 2010 10:20, MJ Ray wrote:
>> Thomas Dukleth wrote:
>>> For those who lack sufficient time to consider proper reasoning, I
>>> present
>>> my brief conclusion before the analysis on which it is based.  I favour
>>> testing a good multi-lingual implementation of MediaWiki modeled largely
>>> on the Wikipedia implementation which I expect to be the best wiki
>>> choice
>>> for the long term future of the Koha project, especially in relation to
>>> support for internationalisation. [...]
>>
>
>
> 1.  AVAILABLE TIME.
>
>> Oops! I've even lacked sufficient time to read this email until now!
>
> I have mostly not had sufficient time to attend to the mailing list
> recently myself.
>
> [I have been collaborating with another programmer on a sadly non-library
> related project which must be finished before I turn into a pumpkin.  When
> the person with whom I have been collaborating has disappeared for a few
> days at a time, then I have had some time for Koha.  Finishing the project
> which is keeping me from Koha is a better time availability remedy for me
> but that remedy has not been solely dependent upon me.]
>
> I should have some more time for the wiki next week.
>
>
> 2.  CONCISE EXPRESSIONS.
>
>> 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.
>
> In the present case, I think that my effort has not progressed quite far
> enough for me to be both concise and informative.  I should be able to
> give a concise expression of reasons at a later point.
>
> I do not seek obfuscation by trying to give detailed information for those
> who care to read at length.  Lack of concisely expressed reasoning should
> not be presumed to be the same as reasoning which could not be expressed
> concisely.
>
> When I have had the time to test an implementation sufficiently, then I
> should also have time to express my reasoning concisely.  I have only
> advocated testing the utility of MediaWiki but not formed a necessary
> conclusion over a test which has not yet been sufficiently configured and
> conducted.
>
>
> 3.  WIKI CONTENT RELICENSING.
>
>>
>> I'm happy to see that the content licensing might be solved as a
>> consequence
>
> PTFS now controls the uncast LibLime vote for relicensing some significant
> wiki content.  I am still hopeful that PTFS will express themselves
> favourably on such a minor issue to avoid the need to rewrite some helpful
> content contributed by LibLime which would be well worth transferring to
> any new wiki.
>
>
> 4.  WIKI FARMING.
>
>> and that people are willing to work on farming the wiki,
>
> I am willing to put much work into a wiki in whatever form people agree
> the wiki should take.  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 .
>
>
> 5.  WIKI CHOICE.
>
>> 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.
>
>
> 5.1.  EXERCISING CHOICE.
>
>>
>> To be clear, I am disappointed with the preselection of mediawiki
>
> I only just now noticed that the subdomain wiki.koha-community.org
> resolves to something.  Thankfully the link from koha-community.org does
> not point to the new subdomain.  I have never advocated preselecting a new
> wiki.  In my previous message, I had advocated setting up a test
> installation of MediaWiki.  I had presumed that after a test would be
> fully configured and available for testing for a period of time, we could
> then vote on whether such an installation would be a good choice for the
> Koha community.
>
> Galen Charleton identified the fact that [aside from the criticism of the
> 'heaviness' of MediaWiki implementations given by Frédéric Demain] no one
> had raised an objection to using MediaWiki.  Obviously, you have now and
> any serious objection deserves serious consideration by everyone
> interested.  I had raised the issue with Galen that we should have a
> formal vote after a suitable test.
>
> Galen suggested to me selecting according to what wiki would actually be
> used in practise.  People would vote with their use.  I find Galen's
> suggestion of voting according to use appealing, although, I had not
> properly considered some possible issues of fairness in how the
> alternatives are presented if MediaWiki would be the only new alternative
> and the old Koha wiki would be the only DokuWiki alternative presented.
> Galen's suggestion has certainly provided me with the motivation to
> resolve implementation issues more quickly than I might have otherwise
> given my constraint of time from other work.
>
> I have been working on issues which needed to be addressed for the
> MediaWiki installation hosted by Equinox.  Galen has done a good job of
> starting that installation with daily database dumps and version control
> in Git for any modifications of the scripts but a few important initial
> configuration issues have been missed.
>
> The MediaWiki database needs to be dropped and reinstalled with the
> MediaWiki in a slightly different directory within the home directory for
> the wiki to avoid the namespace collision currently preventing the use of
> cool short URLs familiar to users of Wikimedia foundation installations of
> MediaWiki such as Wikipedia,
> http://www.mediawiki.org/wiki/Manual:Short_URL .  There may be a way of
> correcting the issue without dropping the database but especially without
> any significant content yet dropping the database would be the easiest
> remedy.
>
> I think that wiki.koha-community.org should merely direct users to an
> appropriately localised wiki similar to what is done from
> http://www.wikipedia.org .  A simple change in DNS and Apache
> configuration could provide for language specific subdomains.
>
>
> 5.2.  REASONS INVOKING POPULARITY.
>
>> apparently mainly on grounds of popularity (which is repeated to argue
>> for everything from translations to scalability),
>
> 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.  I never favour popularity for its own sake and
> usually favour choices which are only popular with the well informed
> minority and not the public at large.
>
> I merely want a wiki implementation for Koha is best suited to growing
> with the growth of Koha and the growing diversity of the community.
>
>
> 5.3.  ADMINISTRATIVE AND ACCESSIBILTY ISSUES.
>
>> while ignoring its
>> many configuration and accessibility problems
>
> Administering MediaWiki has a much heavier administrative burden than
> administering DokuWiki.  I am willing to take the time to learn and
> implement the most helpful techniques, extensions, and bots to use for
> both easing the administrative burden and enabling the features which
> would make the greater effort required worthwhile.  Did you mean to refer
> to anything else, aside from administrative complexity, in terms of
> configuration problems?
>
> 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.
>
> Do you know of any other accessibility issues for MediaWiki and are they
> any worse than accessibility problems of DokuWiki?  Serious attention
> seems to be given to accessibility for MediaWiki,
> http://blind.wikia.com/wiki/Mediawiki_and_Accessibility .  Guidelines have
> been written for maintaining good accessibility for Wikipedia articles,
> http://en.wikipedia.org/wiki/Wikipedia:Accessibility
>
> Historically I have had problems with JavaScript in both MediaWiki and
> DokuWiki but I have not had such problems in the past couple of years.
>
>
> 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?
>
> 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.  Camel case wiki
> links can be turned off in DokuWiki.  People should express their
> preference for or against camel case.
>
> I presume that a design providing for collaboration in creating and
> editing content and a simple markup syntax relative to HTML would be
> criteria for identifying a wiki.
>
> The first wiki created does not seem to have the one and only canonical
> syntax which may be good for the development of wikis.  Perhaps there
> should be a W3C standard for wiki syntax but I do not know of any effort
> to create a truly common standard amongst wikis.
>
>>
>>
>> I'm not going to Fisk the whole essay, but I'll comment on a few:
>>
>
>
> 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.
>
> I have created a DNS configuration file which maps every language listed
> at http://translate.koha.org/ to a language specific subdomain using the
> familiar two letter ISO 639-1 language code where available and the less
> familiar three letter ISO 639-2 code where no two letter code is
> available.  I have interpolated a code with a hyphen for some language
> dialects or other variants which may need separate localisation for
> linguistic or cultural reasons and for which no ISO 639-2 code exists.
>
> Configuring a MediaWiki family well is a little tricky and I prefer to
> leave English as the only wiki until I have had time to test an
> implementation on my own server to have confidence that my first attempted
> multilingual implementation will not break MediaWiki on the Equinox
> server.
>
> I have been studying the Wikimedia Foundation configuration files,
> http://noc.wikimedia.org/conf/ , not to slavishly copy them but to learn
> who they are used to manage such large wikis.
>
>> 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.
>
>> 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 .
>
>
> 5.6.  REVIEW OF REASONING ISSUES.
>
>>
>>
>> Popularity: if user numbers decided things, we'd all be using whatever
>> ILSes dominate our sectors.  They don't and we use Koha.
>
> I agree that mere general popularity should not govern individual choice.
> Where collaboration is required for a wiki to serve its intended purpose
> and we cannot switch wikis with a simple system preference, then we need
> to take a choice as a community.  After we have been able to run a
> suitable test, then we should be able to have a vote.  I like Galen's idea
> of voting by use over time but I have some concern that a comparison may
> not be sufficiently fair without multiple competing community
> implementations.
>
>>
>> Configuration problems: most MediaWiki sites have settings which are
>> fine for wikipedia but are poor for small projects.  My obvious example
>> is the copyright and terms pages.  Are you sure you can get them all?
>>
>> Accessibility problems: I often can't add links to wikipedia because
>> it always wants me to pass an evil eyetest.  If that is switched off,
>> does it have any proper spam defences?
>
> There are many extensions which provide spam protection in MediaWiki.  We
> should not use an extension which causes accessibility problems.
> MediaWiki installations are reported to be  popular spam targets, however,
> without having the popularity of Wikimedia foundation sites such as
> Wikipedia, the Koha community should not need to use spam defences which
> are not implemented reasonably.
>
> We once solved spam problems on the Koha wiki by simply imposing an
> htaccess password form with the password embedded in the form information
> label for easy entry by humans.  Spam problems later subsided as a
> consequence and we later removed the htaccess form without adverse
> consequence.
>
>>
>> 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.
>
> 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.
>
> New feature elements for reducing complexity in editing the most complex
> content on MediaWiki pages have been announced for implementation on
> Wikimedia Foundation sites such as Wikipedia from the development branch
> of MediaWiki.  I suspect that it would take several months before such new
> features for reducing the complexity in complex content to be included in
> a stable release of MediaWiki.
>
> [...]
>
>> 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 .
>
>>
>> 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.
>
>
> 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.  I
> identified a problem for URLs further above for which we should drop the
> database and start again in a new subdirectory on the file system before
> anyone adds any significant content.
>
> My significant experience with DokuWiki and what I have learnt from
> studying MediaWiki persuades me that DokuWiki is only the second best
> choice.  However, I suspend a proper conclusion until concluding proper
> testing.  I have investigated other options but we should all be open to
> good suggestions.
>
> Do you object to testing in use as Galen had suggested?  I am willing to
> spend the time to move any content created in a wiki implementation tested
> in use to whatever wiki implementation the community would choose.
>
> We should always have time to reconsider any decision once a decision once
> a decision would actually be taken.
>
> [...]
>
>
> Thomas Dukleth
> Agogme
> 109 E 9th Street, 3D
> New York, NY  10003
> USA
> http://www.agogme.com
> +1 212-674-3783
>
>
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>