Appreciate the feedback.
Using Transifex instead of WTI; dropping the wiki, thus requiring a GitHub account to contribute; losing existing translations, …
I looked at more classical CMS like Wordpress, but also had a look at Drupal, TYPO3, MODX… Basically, in some cases, we simply couldn’t achieve everything we want, or managing the site would be so complex that we wouldn’t gain anything. Even more significant, using those systems would require some kind of backend account, and if you start looking at CMS with file-based backend so we could make the contribution process more streamlined… yeah, not so much. There is a non-zero chance I missed something, but I feel pretty comfortable claiming that building something tailored is likely the best idea.
Ah yeah, that was a fragment from me adding the edit button to the footer while being at a conference. I was aware of that issue, but didn’t find the time to address it. That now is fixed. However, there isn’t much translated content, but at least the “select language” selector will be German.
Everything is discoverable by search robots. Well, everything but the individual steps inside the installation guides, because the selector is based on JS, but the installation index page will be indexed, so that’s a non-issue. There is no hidden content unless we mess up, and even all the FAQs/Guides are listed in a simple list-of-links, for example here, which contains all guides, not just the top n, and this will also list all release announcements.
One thing that we need to do is to make sure to 301 redirect old URLs to the new site, which will make sure we don’t lose the search rank of our old website, but also will make sure people won’t get lost in old bookmarks.
The fun thing about that question is there is only one valid answer: I dunno.
Content itself should be pretty convertable, given it’s literally just a bunch of markdown files. With everything else, well, it depends on what the new site looks like. This is hard to plan, and so impossible to account for. In general, though, adding new subdomains for example should be simply done by adding a new section to the config. Other types of interactive contents could be build by adding a new module to site_modules and including it, … but that’s all things I can imagine right now. There probably will be another large-scale reinvention in 5 years from now, but that’s nothing bad.
I planned in adding a layout key to the frontmatter, just like jekyll did. In fact, there is even a views/layout directory, and MderbRenderer::mderb takes a layout parameter.
The thing is… I didn’t need it. I managed to build everything we have right now without the need for a second layout. So I didn’t implement it. If we ever need a second layout, we just need to add the layout key to the frontmatter, and implement a way to provide frontmatter defaults like jekyll does, and that’d be it.
Caches, in general, are evil. If you absolutely need them, they are still evil, but a necessary evil. But we don’t need them.
Everything is being rendered on demand, where “demand” is a http request. What this thing does in production is to load all files into redis, but only the files. I parse the frontmatter YML into a serialized object because parsing YML is surprisingly expensive (okay, it’s actually not surprising, but that’s off-topic), so this gets stored as a marshal’ed object, but the site’s contents are stored as unparsed mderb source. There are too many edge-cases we’d have to consider with caching.
As for salability… it doesn’t really matter. Startup times will get slower if we have lots of sites, but that’s only startup. Let’s just quote the redis docs for the command used to lookup pages here:
While the time complexity for this operation is O(N), the constant times are fairly low. For example, Redis running on an entry level laptop can scan a 1 million key database in 40 milliseconds.
We will not get to one million pages. Ever. Even with 100 translations, that would still be 10.000 pages. I don’t see that happening. Parsing markdown/erb has a cost, but I couldn’t reach the limits of that with doing a load test with ab on my macbook running a single puma thread, so… While response times won’t always be the amazing 4ms that it currently has (that is excluding reverse proxy and load-balancer roundtrips), it won’t be at the 40ms of the current site, or the super fast 310ms on average for a wiki page render.
To me, this is actually less about claiming to be a foundation (which, let’s be honest, nobody cares anyway), but more about readability and type-ability of that domain. diasporafoundation is actually really read to read and type for people with subpar English knowledge, and although we casually ignore that userbase most of the time, I’d like our official website not to do so.
Quite honestly, me neither. Here’s the thing, though: FAQ works in English, but that abbreviation is impossible to translate. Most projects stick with “FAQ”, but it turned out that that’s actually pretty horrible. The term is very well known within technical circles, but outside of that circle, most people are actually really confused. The traffic on the FAQ wiki pages is, compared to other pages, shockingly low.
With “guides”, I hoped to pick a term that’s both easily translatable, and more meaningful to users. Although it’s not super accurate, it makes clear that behind that link, there is content that explains how something is done. Besides that, it kinda forces us to write the contents in a different way. Instead of just answering hypothetical questions, it puts us into a position where we have to find topics to explain in a guide-like fashion. “How text formatting works”, “How can I discover contents?”, …
Does that change your opinion on that? If not, that’s probably a good sign we should reconsider that. 
* you people.
You can make this discussion public, but no need to call for a vote in my opinion. You did an amazing job, now let’s go ahead, fill it with content, polish the design and push to prod! 
(There are more intermediate steps, obviously, but I’m getting excited 
thing to do anyway. As mentioned, once the contents are in a state where translating makes sense, we will reach out to everyone and explain how the whole process looks like.
