search

coopdevs / coopdevs-old-web

coopdevs.org content
http://coopdevs.org
2 stars 10 forks source link

Refactor multilanguage implementation #31

Closed sauloperez closed 5 years ago

sauloperez commented 5 years ago

Description

I refactored the site to use jekyll-multiple-languages-plugin. This plugin adds a folder for each language defined in config. As a result we moved all posts to each language folder so that we keep the current behavior of mixing languages.

Now, to add new pages we'll have to add the template plus its translations. That is, about.html with a call to translate_file, plus the files _i18n/ca/about.md and _i18n/es/about.md.

Then, all translation keys live in either _i18n/ca.yml and _i18n/es.yml.

:warning: Something I just realized is that

The main administrator @Anthony-Gaudino, has disappeared so we are in a bit of a sad state here. I still have access to the Ruby Gem and can release new versions but I do not use any Jekyll sites and have no way of verifying PRs. In short this project really need a new owner, is that you? Or can you atleast verify all PRs so I can merge and make a release?

Source: https://github.com/Anthony-Gaudino/jekyll-multiple-languages-plugin/pull/125#issuecomment-432645628

After seeing people using home-made solutions and other plugins I can tell this is one seems the best to me. Even, if we need to, we could mess with the code. It's not a big deal.

See more details in: Anthony-Gaudino/jekyll-multiple-languages-plugin

Fixes

I also took the chance to fix Seguir leyendo. We were displaying it in both Catalan and Spanish. Now that's translated.

enricostano commented 5 years ago

Is this Jekill plugin supported by GH Pages?

sauloperez commented 5 years ago

That's a good point. It just adds extra build steps but I'm not sure how that relates to GH's build process... I bet not very well... :see_no_evil:

andresgutgon commented 5 years ago

The build can happen in your machine. It should not be a problem afaik

sauloperez commented 5 years ago

We'll need to do https://github.com/coopdevs/coopdevs.github.io/issues/33 first.

enricostano commented 5 years ago

The build can happen in your machine. It should not be a problem afaik

In that case we loose the automated build/deploy on code change, that's the main selling point of GH pages IMHO.

This is why I started to investigate how to support Jekyll deploys on our servers: https://github.com/coopdevs/coopdevs-provisioning/blob/master/roles/coopdevs.org/files/post-receive

It works, but we still don't use it.

andresgutgon commented 5 years ago

What about Netlify? It's more flexible than Gh pages

andresgutgon commented 5 years ago

Anyway this it's juat build in local machine and push to gh-pages branch. Not hard to implement. Does people change content on this side from GitHub UI? If all the changes are done by a developer I would stick with Gh pages

enricostano commented 5 years ago

What about Netlify? It's more flexible than Gh pages

This is why I stopped investigating our solution, I wanted to try Netlify.... but, you know... time...

If all the changes are done by a developer I would stick with Gh pages

We have/want more people than developers to be able to contribute to our projects, that's why I would keep the build and deploy automation in place.

sauloperez commented 5 years ago

Up & Running 🎉 !