Re: Internationalization on the new site

Florent Daigniere <[email protected]> Sun, 30 Oct 2016 18:33:48 +0100
Newsgroups	gmane.network.freenet.devel
Message-ID	<[email protected]>
My favourite solution would be based on AWS:

S3 for storage, cloudfront as a CDN in front

A Lambda function to trigger rebuilds when the bucket is updated (or an
api-endpoint we'd get github to trigger on commit)


As for the static-page generator, I am allergic to ruby's ecosystem. Not
because it doesn't work but because maintaining the dependencies over-
time is just impossible.

I'd suggest 
https://gohugo.io/ (a static page generator built on golang - static)
https://github.com/ryansb/hugo-lambda
or Pelican (a python-based one that's maintained/available in pip)

Florent

On Sun, 2016-10-30 at 16:51 +0000, Ian Clarke wrote:
> On Sun, Oct 30, 2016 11:37 AM, Dan Roberts [email protected]
> wrote:Shall I proceed for the moment assuming that we're using github
> pages?
> 
> If we abandon github pages, that frees me to identify and select a
> more
> 
> i18n friendly site generator, so I haven't put much more work into the
> 
> Jekyll version. At present the Jekyll version's English translation is
> 
> effectively complete, however I do think some content curation will be
> 
> necessary to better fit the new format.
> 
> 
> I think this requires discussion, let's consider the options.  I think
> we can
> all agree that we're looking for a solution that is a) cheap or free
> and b)
> hosted by a 3rd party, so we don't have to worry about
> security/scalability/etc.
> Github pages is definitely the easiest, and it's free, and you're
> already down
> the road with that through Jekyll, but it sounds like the experience
> for
> non-English-speaking users will be suboptimal, perhaps relying on a
> JavaScript
> powered redirect, which itself may rely on a 3rd-party service since
> JavaScript
> apparently can't tell what the user's preferred language is (even
> though it is
> part of every HTTP request).  It is also worrying that Github Pages
> doesn't
> support HTTPS for a custom domain - might this result in broken
> inbound links?
> Google App Engine gives us a lot more flexibility, but it would also
> be a
> reasonable amount of additional coding, and probably wouldn't be as
> amenable to
> collaborative editing as Github Pages.  GAE isn't free, but the cost
> is likely
> negligible given how much traffic we get.
> A possible compromise would be a simple redirecting service on Google
> App Engine
> which only served to identify the user's preferred language, and then
> redirect
> to the appropriate page on Github Pages (or set a cookie that is
> visible from
> JavaScript).  Again, more work, and could be messy (we'd probably need
> to use a
> different subdomain for the Github Pages site).
>  
> Thoughts?  What other options are there?
> 
> Ian.
> Ian Clarke
> Founder, The Freenet Project
> Email: [email protected]
> _______________________________________________
> Devl mailing list
> [email protected]
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
signature.asc (application/pgp-signature, 455 B)