Add translations support

[dannycolin]

Recently, a couple of teams formed with the goal to translate MOOC's modules in other languages than english (see main/#31). So, I tought it'll be nice to also translate the website.

Before that, there's a few things we need to consider before starting translating the website.

First, Jekyll doesn't support multilingual websites out-of-the-box. There's plugins for that but they aren't maintained a lot. But, there's other static site generators like Hugo that have this functionality builtin.

Second, I'm actually working on a redesign of the website (It's almost done). Adding the ability to translate the website would then means we'll have to postpone the launch of the redesign if we decide to move to Hugo. However, I think moving to Hugo has more pros than cons in the long run.

Any suggestions, questions?

[geyslein]

@dannycolin I'm with you, we should definitely decide about migrating jekyll => hugo or not before we start translating :)

I see that hugo is more enterprise - more suitable for bigger websites, than jekyll and supports multilingual sites from the scratch which can be a bit more painful with jekyll. I base my judgement on this article https://forestry.io/blog/hugo-and-jekyll-compared/.

However, I am not well informed on the actual status of multilingual support in Jekyll, somebody is more into this? How much extra effort would a migration cause?

Bottom line so far, slightly pro Hugo :)

[jcolomb]

Hey. I have been using hugo quite a lot at my level. For me it seemd the existing templates are quite simple and difficult to change (but that's maybe only me: I have not use jekyll at all...)
If moving to hugo, it would be worth looking into the academic template which seem to be more complete in terms of what one can do.
I would lauch the new (not translated) website independently of creating a new version with translation later (in hugo or not).
Integration of hugo development with rstudio (via blogdown) is a great plus.

[dannycolin]

@geyslein I base my judgement on this article https://forestry.io/blog/hugo-and-jekyll-compared/.

Just a little addendum: Hugo now supports assets' pipeline (e.g sass, poscss, minification of css/js/html, etc)

@jcolomb For me it seemd the existing templates are quite simple and difficult to change (but that's maybe only me: I have not use jekyll at all...)

Are you talking about the template engine? If yes, it has the same features, if not more) as the one in Jekyll (Liquid). It's also possible to use a different one with Hugo or to extend the current one if we really need it. IMHO, I think the builtin one is enough for our needs.

@jcolomb I would lauch the new (not translated) website independently of creating a new version with translation later (in hugo or not).

I'm OK-ish to launch the redesign even without Hugo but I'll only fix the remaining bugs/suggestions. IOW, I won't add new features that aren't already in it (osmooc.dannycolin.com).

Integration of hugo development with rstudio (via blogdown) is a great plus.

It is also easier to spin Hugo locally on Win, Mac or Linux vs. Jekyll. ;)

[tosteiner]

Sorry, am a bit late to the party, but Grav (which plays in the same flat file-based universe as Hugo, but isn't a static site generator per se, but more a CMS) has a multilanguage support feature, see https://learn.getgrav.org/16/content/multi-language

Not sure if that helps?

[dannycolin]

Sorry, am a bit late to the party, but Grav (which plays in the same flat file-based universe as Hugo, but isn't a static site generator per se, but more a CMS) has a multilanguage support feature, see https://learn.getgrav.org/16/content/multi-language

Grav is very an awesome little CMS but there's a few downsides with it. GitHub and GitLab don't support PHP language which Grav is written in. That means we would need to pay for a webhosting plan. Also, it'll involve more configuration. We'll need to link the webhosting and the source code repository to make sure that any change made to the code is pushed to the production server.

I mean those things aren't necessarily hard to do but we'll still need someone to do it. I think the advantage of a static website is the low barrier entry to code and configure it versus maintaining a CMS.

[tosteiner]

@dannycolin ah, okay, I see - yes, definitely valid points 👍 the less work the better ⭐️ (didn't take into account that the site content is basically living on GitLab/Hub...)

[jcolomb]

@dannycolin : I meant using hugo themes as templates (starting from scratch is way over my competencies, and I must admit I did not get much of the jargon you used :) ).
But I will be much more confident to help with the website content creation if it is hugo based, it also seems to me it is much more valuable to learn hugo than jekyll nowadays :)

[dannycolin]

I meant using hugo themes as templates (starting from scratch is way over my competencies, and I must admit I did not get much of the jargon you used :) ).

@jcolomb: Aha! I don't really know any good theme. Personally, I always start from scratch because it's easier that way. I don't have to learn the source code and I can make sure my code respect the web specifications especially the one on web accessibility.

If you're interested to learn a bit more and don't have a lot of time, I strongly recommend the video tutorials from Mike Dane. And if you don't understand something in the OSMOOC source code don't hesitate to ask questions ;).

[jcolomb]

I would probably be worth looking at the academic theme before writing everything from scratch.

Independently, it would be cool to make the website dat compatible. One "only" needs to make sure external components are called with "https://" and that no baseurl is used. I would also think about downloading the dependencies (CSS most of the time) instead of linking to them.

Regarding decentralised web, It might be interesting to look at a way to use dokieli (https://dokie.li/) to allow people to make comments. It is still very not easy no use, but it has great potential, especially in term of data control.

But for now, is there anything we can do to get the website update ready for deploy (pre-hugo)

[dannycolin]

I would probably be worth looking at the academic theme before writing everything from scratch.

We have a lot of custom templates/pages and I'm following the WCAG guide that the vast majority of themes don't follow :/.

Independently, it would be cool to make the website dat compatible. One "only" needs to make sure external components are called with "https://" and that no baseurl is used.

Every libraries are loaded from the main domain (opensciencemooc.eu) so I only use relative url ;). For external url, we can also use "//" it's protocol agnostic and it has the advantage of not breaking websites url that still don't support https.

Regarding decentralised web, It might be interesting to look at a way to use dokieli (https://dokie.li/) to allow people to make comments. It is still very not easy no use, but it has great potential, especially in term of data control.

@jcolomb can you open a new issue for that?

But for now, is there anything we can do to get the website update ready for deploy (pre-hugo)

I'll push what I did during the weekend tomorrow on the v1.0 branch. I'll need someone to look if the content doesn't have any typo, if some information is missing, etc. If everything goes well, the redesign should be ready at the end of the week.