Projects

The Kiwix volunteers program has for purpose to offer to motivated and talented people ways to work for Kiwix during a limited time.

Tasks

Kiwix for Android

Always more people use smartophones as medium for their digital life. This is especially the case in emerging countries which are targeted by Kiwix. We think Android will be the most important mobile platform in the next years, especially for the cheapest devices. Android is in addition, to the opposite of the Apple app. store, open to free softwares. Consequently our next big step, is to port Kiwix to Android.

We do not want to start an other software which would generate a lot of additional code to develop and maintain. So, current Kiwix code base has to be reused and ported. Kiwix runs currently with the help of Xulrunner, but it can also runs perfectly using Firefox. Firefox can since version 3 is able to launch third party software, like Kiwix. Fennec, Firefox for mobiles, was launched a few month ago for Android, so we hope that Kiwix could be ported to Android using Fennec or something similar (see this example).

We need for this task someone with good knowledges in C++, compilation and with know-how in porting C++ softwares to Android. Someone with enough motivation to build a prototype of XUL (with custom C++ XPCOM components) application running on Android could also match the requirements.

Sugar port

Sugar is a Desktop environment thought for kids. It's especially known to be provided in XO computers of the One Laptop Per Child (olpc) project. Because Kiwix is developed on GNU/Linux like Sugar, there is no principle problem to run Kiwix on Sugar... but they are still things to do.

The first difficulty is that Kiwix should be compiled statically (in a Sugar activity), which is currently not fully finished for GNU/Linux... although is already works for MS Windows and MacOSX.

The second difficulty is to integrate Kiwix in Sugar, that means:

Redesign the User Interface with XUL and CSS
Create the activity
Deal with the journal and such specific Sugar things

For that task we need a developer with Know-How both with Sugar and GNU Autotools.

Collect informations about our audience

As Kiwix grows more in popularity it would be really nice to tell the stories of the organizations that are using it. If we know who's using it then we can ask those people to let us know how we can make it better. It would also allow us to better understand the reach that our offline projects and how fast we are improving us.

Currently with think in the following directions:

Get more informations about the downloads and develop KPIs
Setup a system to allow user to give us a feedback (see Tomasz's email)
Improve/simplify bug reporting and feature requesting (being able to leave an email adress without registering, simplier).

New Web site

We need to replace the current web site by a more simple and fancy one. The current one is too complicated for the average customer and mix informations for devs and end users. In addition it does not provide some features which are essentials like a simple an intuitive way to search over the ZIM library or a simple way to give a feedback (bug report or feature request). So there is a lot of improvement potential in both content and visuals.

This new one should be based on Mediawiki and we already have a design. The wiki part, like we know it, would be still accessible but not push on the front of the Web site. So we need someone we good PHP & Web languages knowledges to do that.

Compilation Platform

Kiwix is currently ported to 3 different platforms: MS Windows, Apple MacOSX and GNU/Linux. In addition, and this has to be kept in mind, they are many GNU/Linux distributions and also two architectures per platform. So we speak here of 10->20 files we have to prepare each time we release a new version of Kiwix.

We currently do that manually and because we do not have a lot of packagers, most of the work is done by developers... by hand. We support always more platforms, so this takes always more time and consequently brakes the whole release management. In addition, doing that manually is a big source of errors.

So we search someone to build a global software solution to fix that issue. This solution should allow to build all this files with only a few clicks or commands. This Solution should be fully documented and as cheap as possible. We think this should use virtual machines to avoid the need of a lot of expensive hardware. Our first researches were leading to Mozilla Tinderbox which seems to be the best alternative (but if you have a better idea, we are ready to discuss it):

But, maybe BuildBot or Jenkins could also do the job!

We search here someone with good knowledge in compilation, scripts languages like Perl and/or bash to setup and document this platform.

Mediawiki DumpHTML extension work

The Mediawiki DumpHTML extension is the solution to export hte dynamic generated HTML pages in a set of static HTML/Media files. This extension is the best way to get a good set of HTML pages from a Mediawiki (in comparison with a Web site mirroring tool for example).

Workpackage1: Revamping and fixing bugs

Unfortunately, the DumpHTML extension is not correctly maintained and with the time many issues were discovered. Currently, the extension is not really usable without fixing/tweaking the code.

The purpose of this work package is to fix the most critical bugs that everyone having a Mediawiki would be able to simply get a HTML dumps of his content and consequently easily generate a ZIM file afterwards

After the rewamping, the result should be perfect in HTML similar to what dumpHTML.pl does.

Delivarables:

Revamping dumpHTML and fixing bugs (80-120 hours)

Workpackage2: phpzim creation an integration in DumpHTML extension

phpzim would be a new php module allowing to create/write and read ZIM file directly in PHP. This would be a binding of the zimlib, like pyzim in Python. With this library done, we will be able to create ZIM file directly from the DumpHTML.

To be able to get a ZIM file, the user will have to call dumpHTML.php and specify that he wants a ZIM file output (not a HTML dump) also some other meta informations like title, creator, etc.

So the user will need a system access where the Mediawiki instance runs and also to install phpzim (should be packaged).

Deliverables:

phpzim (40 hours)
updated dumpHTML (20 hours)

Workpackage3: Integrating Collection and DumpHTML extensions and new features

By integrating the DumpHTML and the Collection extension we want to give to everyone the capacity to easily create small ZIMs from the Wikipedia user interface with following advantages:

exactly the same rendering as online
no external dependency to install for the Mediawiki admin
rendering done by MediaWiki (as fast as online browsing)

In addition we want to implement a few additional features (see the list of deliverables).