This pull request superceedes #18 and contains all its changes + language icons.

[NxtChg]

Switching languages respects current page, so when you switch you will be at the same page, but different language. Russian translation provided by Har01d.

[NxtChg]

Abort, abort, abort :)

Doesn't work.

[NxtChg]

For some reason it gets the link of the view, not the page.

request.fullpath should probably be replaced by something like request.url

Strange, it worked in my setup...

[Har01d]

Also I think you should change icons' links to "index.html", because "Bigger blocks" and "Take part" link to index.html, not to welcome.html.

[NxtChg]

No, that's fine. index.html IS welcome.html

[NxtChg]

Another problem is when user first lands on the site, his url is not index.html, so this needs to be fixed too.

[Har01d]

Another problem is when user first lands on the site, his url is not index.html, so this needs to be fixed too.

That's what I'm talking about. If user lands on welcome.html and clicks on "Bigger blocks" link he gets redirected to index.html instead of staying on the page.

[NxtChg]

Mike, could you do a simple replace of request.fullpath by request.url on the site in layouts/default.html.erb and see if that fixes at least the main problem?

[mikehearn]

I already noticed this and am fixing it right now.

[NxtChg]

Seems working.

[NxtChg]

@Har01d this is not a problem, because welcome and index are synonyms.

[mikehearn]

I have to admit I don't like serve much. It even breaks aws syncing because it rewrites the entire website output every time something changes, so even a single letter fix results in reuploading the entire site. And it seems kind of abandoned.

Man. I hate modern web dev. Frameworks seem to last about five minutes :(

I'll commit the fixes I made. They're kind of ugly but I don't wish to mess around with this.

[NxtChg]

I am 100% with you on that :)

[Har01d]

welcome and index are synonyms

I understand that, but why bother loading another page if you don't need to? That's how anchor links (https://bitcoinxt.software/ru/#sec-hardfork and https://bitcoinxt.software/ru/#sec-takepart) should work. Another option is to change the links themselves to https://bitcoinxt.software/ru/welcome.html#sec-hardfork and https://bitcoinxt.software/ru/welcome.html#sec-takepart respectfully.

[NxtChg]

Well, yeah, but what Mike did is a quick hack anyway, so it works for now, let's leave it like this.

It might actually be a good idea to export the whole project as htmls and redo it in something else, or even leave static htmls and change the language icon link by JS.

For such a simple site I see no reason to use Ruby and frameworks at all.

[mikehearn]

Yeah, switching away from Ruby/ERB/Serve is fine by me. The website is done this way because when Gavin first suggested he'd submit BIP101 to XT if it wasn't accepted into Core, I realised I'd need to turn XT into a real open source project really fast, so I asked for volunteers to help do the logo and website. A startup design agency got in touch and did the work: Ana used whatever tech she wanted and I was cool with that, as I was busy with other things.

If someone wants to find a templating framework that is:

a) Simple

b) Doesn't regen the entire website on every export (optional)

c) Well documented and maintained

and is willing to convert the site over, then I'm all for it.

BTW I fixed the welcome/index thing too.

[NxtChg]

The site has literally 5 pages and the only template is header/footer separation, so something like simple php pages would work just fine. Changes will be localized to individual files, so it shouldn't require any regen.

Maybe there are plans for something bigger, but such sites usually don't grow that much, I mean look at bitcoin.com.

What would be nice is a good translation system plugged in. From what I understand the Transifex suggested earlier is a simple and clever contraption: it first gets all the text strings from your site by JS, then stores them and allows community to translate, then moves them back, again by JS, replacing the original strings. So it also doesn't need any frameworks or templates, but translations need to be hosted on a 3rd party site. Not sure how good it actually is in practice.

Maybe others can suggest something else for both main site and translations.

[NxtChg]

BTW I fixed the welcome/index thing too.

Actually, you broke it again :) Turns out it was a wise decision not to mess with it any further.

Now Patches link doesn't work (English version only).

[mikehearn]

Gah. Fixed, thanks.

The site has to be entirely static as it's hosed off S3/CloudFront. Beyond that it doesn't matter what we use.

[ghost1542]

Well, bitcoin.org uses a static website generator (jekyll) and has a translation system using templates and Transifex ;) . However, it's worth to note that translations have a cost you may want to consider; it makes it much harder to update pages (by having to update both the template and english strings, choose whether to override or use outdated translations temporarily, and the extra work of updating them afterwhile).

As for the static website generator, I think it wouldn't be hard for me to convert it to jekyll if others want this. It's more documented and widely used, and more flexible with plugins (although I may not know about serve features). Otherwise I think it's pretty similar.

As far as I'm concerned, what confuses me most with current setup isn't serve, but how the SCSS files are organized for such a small site, instead of just having one CSS/SCSS file (or otherwise one that imports split stuff in _partials/*, as seems to be the SCSS way of doing things).

[mikehearn]

Yeah. I'm happy to accept refactorings. I think this is a setup intended for a much larger website.

[NxtChg]

@saivann Yeah, CSS is a mess too. Probably better to just use 'export' in serve and then work with that.

As for the static generator, I would simply use PHP or even SSI on the server, if available :)

Again, it's just 5 pages. And for translations: continue using folders with a copy. Seems like Transifex would be overkill.

[mikehearn]

As I said, for DoS resistance the website is CloudFront+S3. No dynamic code. This means serving is very fast, very cheap and basically impossible to flood off the net, even if you have a 25 gigabit/sec UDP cannon. It's not worth losing those benefits just to use PHP.

[ghost1542]

@NxtChg Mmh, keeping track of English string updates isn't really feasible this way. Not using Transifex makes it easier to update the English site, but it's at the expense of making the translation process much more complicate and error prone, possibly unworkable. So I think there's extra work either way, it's more a matter of choosing what this project prioritizes.

[NxtChg]

No, I meant using PHP to generate static HTML's. We only need to include footer and header. Heck, you could probably do it with shell scripts :)

[mikehearn]

Oh, I see.

[NxtChg]

@saivann Yes, you can't magically solve the problem of localization. Either way there will be some work involved. If you make a change, you will have to update all translations. But this site is small and mostly static. So at least for now we can handle manual translation changes.