mwoffliner VS zimit

You can also directly open a ticket at https://github.com/openzim/mwoffliner/issues with as much info as possible so we can look into it (zim name, language, date, article name, etc.)

Welp yes, that's a bug (likely a regression from a recent update). Can you please open a ticket at https://github.com/openzim/zim-requests/issues (we might move it later on but that's as good a starting place as can be).

https://github.com/openzim/mwoffliner/issues/1655 Unfortunate that there's no way to convert the easiest way to make proper dumps of wikis (ArchiveTeam's wikiteam-tools) to Kiwix Zims. That would allow for all sorts of niche information to be preserved in a readable way.

I'm looking at making my own ZIM though not sure the best way to go about it. I've seen zimit on Github and the mwoffliner on Github too.

Generally speaking, I'd advise opening a ticket on https://github.com/openzim/mwoffliner/issues

r/kiwix would be the place to ask, but at the end of the day it all comes down to heading out to openzim.org (or the corresponding github repo) and figuring it out. You can either grab zimit and run it locally, or access all the libraries that will help you build your own scraper (Nautilus will assemble documents and videos into a single file library, MWoffliner will do for wikis, youtube will do YouTube, etc.).

There are clearly similarities between the two, given that Kiwix put resources into making WARC content available in ZIM archives (i.e. Zimit-style ZIMs, created with the Zimit scraper and warc2zim backend). But as u/IMayBeABitShy said, the ZIM specification focuses on providing a highly compressed container that is readable on-the-fly (i.e. by decompressing only the needed content to show an article), whereas WARC, or rather the compressed version WACZ, is merely a zipped version of the WARC data (request headers and responses). It is also readable on-the-fly, but compression will not be as optimal as the zstandard compression used by modern ZIM archives.

I'm looking at making my own ZIM though not sure the best way to go about it. I've seen zimit on Github and the mwoffliner on Github too.

You would have more chances at getting a technical reply to your technical issue by hitting https://github.com/openzim/zimit/issues I believe

The zimit readme says it uses /output as the default directory, so we can use that as the name for our docker's volume.

Zimit. This tool allows you to convert an existing website into an offline ZIM archive. https://hub.docker.com/r/openzim/zimit

which worked quite well for most sites, but still very far from a general-purpose solution.

There is also more powerful/general-purpose scraper that generates a ZIM file here: https://github.com/openzim/zimit

It would be really nice to a "common" scraper code base that takes care of scraping (possibly with a real headless browser) and outputs all assets as files + info as JSON. This common code base could then be used by all kinds of programs to package the content as standalone HTML zip files, ePub, ZIM, or even PDF for crazy people like me who like to print things ;)

There is a limit at 1,000 items for each zim because we don’t want to DDoS unsuspecting websites with requests; and also would not be able to afford the bill If it becomes as popular as we think it will be. But since this is free software, you can obviously cut the middleman by copying, studying, modifying and redistributing the code that can be found here: https://github.com/openzim/zimit or contact us directly and get the full thing for a small fee (tbd, but this should not be a blocker for legitimate uses).

Documentation is available at github.com/openzim/zimit and github.com/kiwix (there's a repo for each platform, kiwix-serve and android are the ones to look at atm for integration of service workers)