Use Static Site Generator

I recommend using a static site generator for the page to reduce duplicated code. When changing something in the header and footer, you shouldn't need to edit all pages.

Maybe F-Droid's website is a good base to start off as it's already localized. Additionally, you would automatically get a web interface for your F-Droid repo like this: https://f-droid.org/packages/de.grobox.liberario/

mentioned in issue #2 (closed)

I totally agree we should do this.

All the static site generators I've looked at are great for starting a new site, but a bit of a pain for importing an existing site. As an alternative I've been playing with Mustache as a simple way of inserting headers and footers into pages.

The only issue so far is that the header and footer contain relative URLs, so each directory needs its own headers and footers. We can easily solve that by converting the URLs to root-relative. That makes it slightly less convenient to preview the site locally (you have to use a localhost web server rather than just opening the HTML files in the browser), but overall it's still easier than converting the existing pages into the format expected by a static site generator.

Hello, my name is Jose Victor and I usually help translating Briar to Portuguese (Brazil). The fact that the Briar website is only in English doesn't help to make it more popular in non-English speaking countries. So it would be nice if there was a way to make the Briar website translatable.

I did a static website with Hugo a few days ago and after some initial confusion, I found it quite simple and up to the task of migrating an existing site to it.

Migrating the existing Briar website to it would probably take me ~3 hours. Add some extra time for news posts and integrating the manual and specs into it.

mentioned in issue briar#1275 (moved)

mentioned in merge request !14 (merged)

@grote Hugo looks very good and relatively simple. Maybe I can help a little once it's clear how you want to do it?

Thanks for offering help! That's very appreciated and needed. However, like you say, we need to decide about a way forward first. The other sane alternative to Hugo seems to be Jekyll, but I personally don't have experience with it.

Hugo does support multilingual sites natively. However that does not necessarily work well with tools like Transifex as they just expect another file per language for the translation.

Jekyll does not seem to support multilingual sites. In their documentation, they just link to a plugin that was last updates 4 years ago. However, there's many ways to add localization support. F-Droid has their own hacky system that uses gettext which would work with Transifex.

I think multilingual support is an important prerequisite for making Briar better known. I tested it with Hugo, and it works great.

I will take the time to press the existing Briar website into a Hugo template as PoC. If that's helpful?

@micressor thanks for the offer! The problem is that translating the site should be integrated into our current translation infrastructure. Ideally, it shouldn't involve learning markdown, git and pull requests.

@grote I understand the problem. Hugo has i8n support, but you would have to work with many variables in the markdown files, I guess. Similar to the string files in the Briar app. It takes a little more research.

Tor Project is moving to Lektor which also supports i18n, but as well only through entire pages.

F-Droid is currently looking into migrating their site from Jekyll to Hugo, because Jekyll sucks is super slow.

I'll try to build a PoC with hugo. This will take some time due to limited time.

I'll get back to you. Here is the wip-feature-hugo-migration branch.

mentioned in merge request !24 (merged)

closed via merge request !24 (merged)

mentioned in commit b023b8e9