Add .onion and offline links if available so the user has the choice if he wants to use HTTPS or .onion URLs or an offline version.
Maybe also a slightly different version for the regular Firefox (formerly Iceweasel) browser with a warning that suggests the use of the Tor Browser? (think I remember such a warning when starting Iceweasel, was it removed? or has it stopped working?)
That would be great and very nice off you. What kind of approach would you take in regards to translation? Fully replace the current plugin with something custom?
I was thinking about just replacing placeholders and have a list of replacements for each language and fall back to English if a string is missing. This is a very simple solution but I think it’s the easiest because there are just a few strings. Maybe GNU gettext if a simple list of replacements isn’t enough.
A script that downloads parts of (or the entire) wiki, build an index and makes some changes for offline use (I still have to read through the Offline Documentation Discussion, though it seems that there are some concerns with this approach)
A script that would have to be written. It would take a template and translations and produce multiple HTML files (one for each language). Maybe “build script” was the wrong term?
I don’t think it’s a good idea to download from whonix.org during the package build. It’s a remote, live, changing location. Not a source file.
Would be a break of the security model. I consider whonix.org a binary format. All Non-Qubes-Whonix VM images for now have been produced locally from source code on my developer hardware. (Except for binary Debian packages which are installed inside VM images as is from Debian repository.) Adding a binary file (the pdf) that I generated from the Whonix web server would break that model.
Since it’s a changing location, it would also break (future) reproducible builds.
The offline documentation would have to be created from source files.
But even https://github.com/Whonix/whonix-wiki-backup is not vetted. It’s auto generated on whonix.org server using git-mediawiki as backup tool. A breach of either whonix.org or github.com could lead to malicious content in these unvetted, auto generated source files and once a user clicks these, they could get compromised.
I think for offline documentation we first need to fix the documentation security model. That is, documentation is edited as source files on github. Whonix developers then keep merging and signing changes for being non-malicious locally. These source files would be used to create the website html. Not the other way around we are currently doing it. It might mean to move away from mediawiki. A lot work.
Tor Browser changes are hard to apply consistently. Since it’s not packaged, so very messy. And any modification could break it’s internal updater. So probably not a good idea to do this on behalf of the user. If anyone should add such changes, it’s Tor Project upstream.
Also, we need to slow down on Whonix features after Whonix 14 (which is already long behind schedule). tor-connection-wizard will be the last major enhancement since it was already agreed to take it and since you’re working on it already.
Next, the maintenance, package build and release process burden needs to be considerably reduced. Automated package builds, automated image builds, build documentation, upgrade sanity tests from version state X, Y, Z to new etc.