On Sat, Dec 17, 2016 at 9:25 AM, Ian Clarke <[email protected]> wrote:
> On Sat, Dec 17, 2016 10:36 AM, Florent Daigniere > [email protected] wrote: > >> On Sat, 2016-12-17 at 16:11 +0000, Ian Clarke wrote: >> >> > Weren't we going to host on AWS? >> >> >> I don't know, that's why I am asking... >> > > Dan? I think your input is required here. > > I have suggested either hugo or pelican with AWS lambda (for a > > completely serverless, trendy infrastructure) > > OR > > using github-pages (with jekyll) and putting some CDN in front > > (cloudflare, cloudfront, whatever) > > > I have not offered to help maintain something ruby based. > > > For clarity, you're saying you would not help to set up a CDN in front of > github-pages because it is Ruby based? I assume that would be ok since > Github is administering Jekyll, not us. > Well unfortunately Jekyll on github-pages doesn't facilitate any usable gettext support that I have seen. It is my impression that retaining our transifex translations is a requirement. > I wish it was that simple. AWS lambda doesn't support ruby as runtime... > > so you have to ship/maintain your own... and write the glue code in any > > of the languages that are supported (java, c#, node, python). You get > > billed when your code runs... so the naive approach of doing what you've > > described above can turn out to be bloody expensive (network round-trip > > to debian mirrors, then to gem, then to bundler, ...) > > That assumes we're using AWS lambda. > > > At the end of the day, I don't care... I've said it in the past; we are > > picking the worst and most convoluted solution possible. I've been > > ignored and can live with it; just don't count on me to make it happen. > > > Well, if you're opposed to it then that's what we'll do! :) > > I don't have an axe to grind here, I'm just trying to have a discussion > the outcome of which will hopefully be a good approach. > > If Dan has built his work on Jekyll then I'm worried it might be a lot of > additional work to switch to something else like Hugo or Pelican, but > perhaps I'm wrong about that. > > Ideally I'd love to outsource our hosting to Github completely to reduce > or eliminate our devops workload, but it seems we can't do that without > compromising on i18n. > > Perhaps the best solution is to switch to Hugh or Pelican and then use AWS > lambda, assuming that can handle i18n, and assuming it won't be an > excessive amount of work to migrate from Jekyll. > > Either way, Dan's input is needed here. > I think we can probably switch to another generator with reasonable effort, but I'm not particularly qualified nor motivated to go out and evaluate a bunch of alternatives. What I was wanted to get across before is that I know exactly what must be done with Jekyll and don't really want to be the one selecting an alternative. *As best as I can tell*, Hugo has no gettext support, Pelican *may* have usable support through an existing i18n plugin, but I have not evaluated it yet. It was not my intention to reject all alternatives to Jekyll, I'm not attached to it, but I haven't wanted to (and still don't want to) lead a search for an alternative, and then redo the existing work. I never viewed automatic generation of the website to be an important requirement, and I offered to be the one to periodically run `jekyll build`, so I still consider Jekyll to be a viable way forward. However, if it really is an important requirement, based on what I've seen so far I'm willing to evaluate Pelican to see if its i18n plugin can suit our needs with reasonable effort. Ian. > > Ian Clarke > Founder, The Freenet Project > Email: [email protected] > Cheers, Dan > _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
