Reply inline: On Tue, March 9, 2010 14:29, Galen Charlton wrote:
Hi,
On Mar 9, 2010, at 6:57 AM, Zeno Tajoli wrote:
I think that wiki doesn't need multiple languages.
However, there's been enough Ukrainian, French, Spanish, and Russian work done on the old wiki that I don't believe this to be a universally-held opinion.
The Koha Wiki should be a place where anyone can be comfortable contributing to Koha in whatever language anyone may find useful. We should not judge everything by the standard for code development where we need a common language to cooperate effectively on the code. The degree of internationalisation of the Koha project is almost as important to me as the free software aspect of the project. The possibility of translating content should not be understood as an obligation to translate anything between different languages. Even having some quite distinctive content in different languages as we have now should be fine. I treat internationalisation in section 2.1 further below. [...]
++ on starting from scratch. A more clear organization is important. But who does he plan the new organization ?
I know Thomas has some ideas.
I will in due course make an organisational suggestion for categories based on the namespaces which had been created based upon the documentation working group led by Pierrick Le Gall at the KohaCon Development Week in France 2006. However, I hope that we will have a flexible idea of categories described in section 2.2 on navigation further below. In future, I might correct some obvious source of confusion, such as defining a category in both a singular and plural form if I happen to notice and have the time to correct something such as that but a wiki is a wiki and should be used as such and not in an overly rigid manner. I hope that we will use the wiki in a manner which helps others find the content which we add so that everyone can contribute collaboratively. I agree with Paul Poulain that we should start over and migrate content selectively. See section 5 at the end for a copyright issue. We should preserve content from the old Koha Wiki which we do not intend to migrate. There is no need to delete old content merely because we do not choose to migrate some old content to a new wiki. Some content which may be thought out of date or otherwise obsolete now may have no comparable up to date equivalent and has some value which someone should still be able to use whenever someone may choose to create an up to date equivalent for the topic. If we had the possibility of easily migrating all the Koha DokuWiki content to a community controlled subdomain, then we should keep everything in DokuWiki at the present time merely because that would be easiest for giving attention to other things such as Koha 3.2. However, we lack an automatic way to migrate the current state of the Koha Dokuwiki content perfectly without the most modest help which may not be forthcoming from LibLime. We could attempt to partly automate a mostly manual process, but the scripting effort might be very significant and the work would still be mostly manual. I favour using the difficulty of the situation as an opportunity to re-evaluate our choice of wiki software and how we would like to implement it. 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. While the testing is being done, I suggest either making modest use of DokuWiki at wiki.koha-community.org or continuing to use DokuWiki at wiki.koha.org. I hope that we would not rush to create a large set of new wiki pages which would then need to be migrated from DokuWiki to MediaWiki with my expectation that MediaWiki will be seen to be an obviously better choice for the Koha project going forward. I have significant experience with DokuWiki administration and modifying some parts of the code. I am only just starting to experiment with MediaWiki. I would greatly appreciate any information which those experienced with MediaWiki can provide especially in relation to multi-lingual support using a wiki family (farm) and multi-lingual navigation in a manner similar to or better than Wikipedia. In any case, we should certainly take the opportunity to adopt the community choice of GPL 2 or later as the copyright license for newly created wiki content in conformity with the license for Koha itself. Displaying notice of a GPL 2 or later license for the wiki content requires modifying the source code of any wiki we may choose. My reasoning and report of my experience with DokuWiki and current investigation of MediaWiki follows. 1. BASIC INFORMATION (FOR ANYONE WHO DOES NOT ALREADY KNOW). DokuWiki has been designed for supporting the documentation of software projects. DokuWiki may have had some features which better supported software documentation than other wikis historically. DokuWiki has been adopted as a wiki for a large number of software projects. MediaWiki has been designed as the wiki for Wikipedia. Its features have been designed to support everything which Wikipedia needs as well as other wiki projects of the MediaWiki foundation and Wikia. MediaWiki is the most widely used wiki because of the success of Wikipedia. MediaWiki is also the most widely adopted wiki generally and may also be the most widely adopted wiki for software projects currently. 2. SUITABILITY OF WIKI SOFTWARE FOR THE KOHA PROJECT. I have examined the range of wiki software available in the past and found that DokuWiki and MediaWiki have been the two wiki programs with the largest number of essential and useful features. I had found WikiMatrix, http://www.wikimatrix.org/ , helpful to roughly compare the features of different wiki software in the past. DokuWiki and MediaWiki are roughly comparable in important and useful features at least with a suitable set of plug-ins or extensions to both. I confine my comment to those two wikis. For the past few years, MediaWiki has had more features and more extensions for additional features. However, having more features which we may never need nor ever use should not be the basis for choice. 2.1. INTERNATIONALISATION. The aspect of the Koha project which I like best after other aspects which are also true of other free software library systems is the degree to which Koha's development and use are international. Any wiki for the Koha project should support internationalisation well. Both DokuWiki and MediaWiki have support for UTF-8 which allows characters for any language to be used. However, there is more to internationalisation than mere character set support. Other issues include the following. Script orientation support is needed for some languages such as right to left languages. Translation of all the elements of the user interface is needed to allow contribution or receptive use without a need to understand a default user interface language. Navigational interoperability between languages is needed to coordinate a common set of topics in which content may be localised in different languages especially where some content will appear in some languages but not be available in every language. DokuWiki has some degree of support for 90 languages, http://translate.dokuwiki.org/ . A large portion of the 90 have very little translated. I am doubtful of the extent to which there is provision for alternate script orientations if any. MediaWiki has some degree of support for 324 languages, http://www.mediawiki.org/wiki/Localisation_statistics . (347 languages are listed but 23 languages by my count have no translation.) A large portion of the 324 have very little translated. MediaWiki attempts to quantitatively evaluate the quality of the translations. MediaWiki has a much larger number of languages for which the translation is almost complete. Arabic for example has nearly 100% translation for standard Arabic and Egyptian Arabic for MediaWiki, but merely 48% translation with no Egyptian Arabic translation for DokuWiki. Given the goal of the MediaWiki Foundation to have a full Wikipedia for every language, MediaWiki is liable to always be ahead of Koha for language support. The narrower scope of DokuWiki is such that it is liable to be behind the Koha project for language support in future. Wikipedia provides an example of a mechanism for linking to every other language in which a wiki article appears. Such functionality is supported in MediaWiki using a wiki family (farm) with interwiki linking. The Interlanguage extension, http://www.mediawiki.org/wiki/Extension:Interlanguage , automatically provides links between pages localised in different language wikis within the wiki family. Attempts of which I am aware to provide similar functionality in DokuWiki in a template or plugin had failed because of the inefficiency of checking the existence of articles in a set of languages as part of the DokuWiki page display code. For the Koha Wiki, we have used language specific namespaces in DokuWiki but that method does not allow interface localisation or different script orientations. 2.2. NAVIGATION. Perhaps the most difficult problem for every wiki is providing a means for users to find the existing content treating a particular topic for reading or to contributing to common content collaboratively. The general wiki expectation is that content is found using wiki links. However, people often create unlinked pages and then a multiplicity of pages on the same topic exist without an efficient means of finding them. One of the first principles of library science is grouping things together by their similarities. The task of similarity grouping complicated by the fact that everything has various aspects on which similarity may be considered and thus has a multiplicity of similarities. DokuWiki provides namespaces which if used provide a degree of automated navigation for traversing up and down a namespace hierarchy, http://wiki.koha.org/doku.php?id=en:wiki:namespace_tutorial . Namespace navigation links are displayed on each page of the Koha Wiki. Global navigation throughout all namespaces is provided by a sitemap, http://wiki.koha.org/doku.php?do=index . The pageaccueil plugin, http://www.dokuwiki.org/plugin:pageaccueil , encourages consistent use of namespaces. Unfortunately, the DokuWiki namespace implementation is a single rigid hierarchy based on the file system hierarchy without the benefit of symlinks. The Tag plugin, http://www.dokuwiki.org/plugin:tag , allows linking from a page to multiple namespaces, however, the page can only be found within the sitemap namespace where the file is actually stored within a directory on the filesystem. MediaWiki has namespaces but uses more flexible categories and category trees for navigation. See http://www.mediawiki.org/wiki/Special:Categories and http://www.mediawiki.org/wiki/Special:CategoryTree/Top_level . Category links appear at the bottom of Wikipedia pages. The CategoryBreadcrumb extension, http://www.mediawiki.org/wiki/Extension:CategoryBreadcrumb , displays category hierarchies in each page for navigation to any part of the hierarchy. The advantage of categories as used in MediaWiki over namespaces as used in DokuWiki is that they are not rigid hierarchies and any page can be included in multiple categories. The disadvantage of categories is that they are not assigned automatically by contextual default. Categories rely to a greater degree than namespaces upon the effort of contributors to assign them. The SelectCategory extension, http://www.mediawiki.org/wiki/Extension:SelectCategory , encourages category assignment and assists users in assigning categories consistently. The Semantic MediaWiki extension, http://semantic-mediawiki.org/ , and associated extensions could be used to provide some automated contextual assignment of relationships. 2.3. WIKI READABILITY. Content is created to be read and used. The easier it is to optically read and follow text, the more attention a reader's brain can give to the meaning of content. My observations in this subsection may be entirely lost on those who may notice little difference between the eye / brain effort required to read a traditional printed book in comparison to the effort required to read the same text on common contemporary computer displays. The possibility that we can become accustomed to working in adverse conditions is not an argument against improving our conditions. DokuWiki page design and CSS pleases some aesthetic sense to avoid dark characters, ragged right edges, and maximise use of screen space. In attempting to satisfy an aesthetic choice, readability is compromised generally and in some special circumstances. DokuWiki low contrast between the background and text impairs readability. I have no claim that the content is actually unreadable, but merely that readability is impaired. The low contrast problem is worst in the page table of contents which uses an especially small font with a similar light weight to the unusually light weight external links. DokuWiki placement of the table of contents to the right of the initial part of the page text can create an overlap problem with page text in Mozilla based browsers, such as Firefox. Fully displayed URLs are part of good practise for some bibliographic styles. Mozilla based browsers never wrap long text strings to the next line which can result in unreadable overlapping content in some cases which is especially likely for long URLs. I used an image placeholder as a workaround to avoid long URLs overlapping the table of contents for a version of a bibliography which I contributed to the Koha Wiki, http://wiki.koha.org/doku.php?id=en:standards:cataloguing_classification:bib... . DokuWiki uses the full width of the screen to present content with almost no constraint on line width. Most of the content in the Koha Wiki is presented in list form for which line length imposes few problems. Scanning from one line to the next smoothly for material presented in full paragraphs becomes a difficulty when lines are unusually wide relative to their height as can now be the case with contemporary wide high resolution displays. Having reasonable line width constraints from margins or other page elements avoids the user needing to adjust his web browser window width to read DokuWiki content more easily. Almost no one is liable to actually adjust his web browser window width for a DokuWiki website when most web pages constrain line width with navigation or advertising columns. There is very little content in the Koha Wiki which uses full paragraphs in the manner which is the common style in Wikipedia but I have been a little discouraged from contributing such content to the Koha Wiki myself in the past with the knowledge that reading such content is unnecessarily difficult in DokuWiki. DokuWiki blind right justification of text occasionally results in a line of text with almost no words each of which is separated by a very large white space. This occasional effect breaks the flow of reading and undoes any advantages of right justification on readability. Right justification is not appropriate for web publication with no control over the absolute window width and font size displayed to the user. The appropriate situation for right justification applied with an understanding of whitespace problems is limited to traditional print material and electronic file formats designed to reproduce the exact appearance of printed material, such as the Adobe Acrobat (PDF) format. Most of the DokuWiki readability problems can be fixed by modifying the DokuWiki CSS. I have maintained such a modified DokuWiki CSS for my own use from 2006. The MediaWiki monobook skin uses CSS based on the highly regarded Plone CSS. Significant work has gone into ensuring that the default Plone CSS has good cross-browser support and readability. Plone CSS and the MediaWiki monobook adaptation are not perfect but they have at least given attention to the issues where DokuWiki has not. [It is always possible to modify the default Plone CSS in a manner which breaks its cross-browser and good readability features. The untested new Plone based Koha website demonstrated that fact in May. One section had display problems in every web browser and the main navigation links were not visible when using default Internet Explorer settings.] 2.4. WIKI SYNTAX. There are some differences in wiki markup syntax and what the syntax supports between DokuWiki and MediaWiki, http://www.wikimatrix.org/syntax.php . While there is much in common between their respective wiki syntaxes, the differences mean that formatted content cannot necessarily be copied between a DokuWiki and a MediaWiki installation and expected to work correctly. There are no sufficiently debugged conversion scripts which I have been able to find, although, I would experiment with creating a very simple conversion script which may be sufficient for most existing Koha Wiki pages. DokuWiki has been considered to have a syntax with the greatest differences to other wiki syntaxes. My favourite DokuWiki syntax feature is the provision for 5 levels of section headings. However, I may be the only contributor to the Koha Wiki who has ever used all 5 levels of headings. MediaWiki as the wiki from the Wikipedia project has the wiki syntax which is most familiar to the largest number of people. I am disappointed that MediaWiki only supports 3 levels of section headings. My own particular concern about the number of levels of MediaWiki section headings could be addressed by either flattening some of the section shierarchies in a few of the pages which I have contributed or breaking some subsections into different linked wiki pages. 2.5. SOFTWARE PROJECT INTEGRATION. DokuWiki and MediaWiki support some functionality to integrate the wiki with other parts of a software project. DokuWiki provides syntax highlighting of example source code using the <code> tag. Some additional plugins extend the syntax highlighting. The gitlink2 plugin allows the use of git commit hashes to link to source code. MediaWiki has source code syntax highlighting extensions such as GeSHiHilight, http://www.mediawiki.org/wiki/Extension:GeSHiHighlight . The BugzillaReports extension, http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports , provides views on the state of bugs in Bugzilla. A link to a bugzilla query would probably be easier. The BugSquish extension allows interwiki links to BugZilla which display the status of a bug. However, intuitive use is complicated by the need to avoid using 'bug' as an interwiki link prefix because the 'bug' prefix is reserved for the Buginese language. 2.6. SCALABILTY AND COMPLEXITY. Frederic Demians is correct in identifying that DokuWiki is much lighter weight than MediaWiki in terms of system resources and administrative complexity. Some increase in complexity is generally required to support a larger feature set. A useful question is whether greater complexity is manageable and scalable. DokuWiki has some efficiency problems which prevent use in a coordinated family of fully localised wikis because of limitations of the file system based design which helps provide simplicity. The simplicity has a corresponding disadvantage for scalability. Wikipedia has proven that MediaWiki is scalable as one of the busiest websites on the internet. MediaWiki would provide more than enough scalability for future needs of the Koha project. As the most widely adopted wiki, there is no shortage of experienced people who may be able to answer a question about MediaWiki administration. 3. DOKUWIKI MODIFICATION. I have been privately maintaining a modified installation of DokuWiki which corrects many of the DokuWiki problems which I have found in the Koha Wiki installation. From 2006, I have maintained my own modified version of the monobook template, http://www.dokuwiki.org/template:monobook . Monobook is designed to emulate some features of MediaWiki. See the current maintainer's site, http://readm3.org/ , and also http://www.pkuinfo.it/ for examples of DokuWiki using the Monobook template. My modifications more closely follow the CSS used in the MediaWiki monobook skin. I also fixed several bugs for Internet Explorer and other web browsers. Additionally, I modified some core DokuWiki page display code to better support navigation elements. I had been working with Joshua Ferraro to test my DokuWiki modifications in 2006. At the stage when they seemed to please him and they should have then been put forward for a community vote, he suddenly lost time to give any attention to them. He had mistakenly suspected an authentication bug in testing where no authentication code had been touched. Stephen Hedges was intending to propose to take the time to migrate the Koha Wiki content to MediaWiki later that year before he obtained a different job which did not grant him sufficient time for Koha. I am pleased to see that the Monobook template has a new maintainer after being abandoned by its author for a long period. However, when the best corrections to DokuWiki problems are to model the design more closely on MediaWiki, then using MediaWiki itself instead of a partial implementation is liable to be a better solution. 4. MEDIAWIKI TESTING. I am working on preparing a test MediaWiki installation following the interlinked languages wiki family example of Wikipedia. The suggestion of the designated easiest method from the wiki family discussion page, http://www.mediawiki.org/wiki/Manual_talk:Wiki_family#Easiest_way , seems better than attempting to follow any of the other incompletely documented methods from the main wiki family page, http://www.mediawiki.org/wiki/Manual:Wiki_family. Even the particular method used by Wikipedia itself is very incompletely documented and perhaps unnecessarily difficult to maintain. Wikipedia runs from the current MediaWiki code from the MediaWiki Subversion source code repository which is maintained as stable for their own use. Using the latest MediaWiki code from the Subversion repository would seem unwise for the Koha project without the resources to devote to maintaining the wiki code when Koha is the Koha project software, not MediaWiki. I am experimenting with the latest stable release version 1.15.1. Supporting the general functionality of Wikipedia using the extensions installed for Wikipedia seems important, http://en.wikipedia.org/wiki/Special:Version . Some functionality which may only be available in extensions for version 1.15 may have been integrated into the core in Subversion and the corresponding extensions would need to be discovered if there are any. I also think that adding some of the additional extensions mentioned above for navigation as well as others is important. Some extensions such as Semantic MediaWiki might never actually be used but that would be no reason not to make them available if some people may have an interest in trying to make use of them. As stated above, I would appreciate any information which others may have to offer for my effort to test MediaWiki, especially as I lack experience with MediaWiki administration and have other commitments for most all of my time. 5. NEW WIKI NEW CONTENT LICENSE. We have held a vote of significant past wiki contributors about adopting a new license of GPL 2 or later for wiki content, http://wiki.koha.org/doku.php?id=relicensing . Any new wiki should have our content license choice which requires a minor change to the source code to display. An appropriate plugin or extension might also be used to display a GPL 2 or later license. Until we have a vote from some who have yet to vote, we should take a little care to not copy some content from the old wiki which those who have not voted had contributed. Rewriting such problematic content should be relatively easy. A few of the most important pages in the wiki fall into that category. I would prefer that we rewrite such problematic content instead of marking it as being under the old license. I hope that everyone who has contributed to the old wiki and is still doing something with Koha will eventually make their vote on the question clear. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 [...]