Add new languages

[rodrihgh]

Currently working in Polish and French

• [x] Translate text
• [x] Integrate text in R code
• [x] Generate Markdown
• [x] Build pages
  • The action does not seem to work. /fr, /pl and /es pages should be rendered (the latest one due to some typo correction), but they aren't @dieghernan
• [x] Add languages to navbar
• [x] Acknowledge translators in "About"

[dieghernan]

It seems we are pushing the limits of Jekyll on this project. I made a few amendments, now it should work, but if we want to add new languages (that means more pages and more build time, leading to the error) we may change the building strategy:

• Now we rely on gh-pages entirely for building the page. This cause timeout issues, since gh pages would fail if the build takes more than 10 minutes: https://github.community/t/page-build-timed-out/10476/3
• Each lang page after rendering (on _pages folder) is about 1Mb. It seems that this is too much for Jekyll on GH pages. I have reduce the resolution of the countries to 60M (lowering the borders definition). This is less points to plot and less size of the page at the end. Countries are polygons, and polygons are points, and each point of each country is written in _pages. Lowering the resolution from 20M (previous) to 60M (current) reduced the size of each page from ~1.5 MB to 1Mb.
• I would not favor to go to lower polygon resolutions, that would make the countries look really bad. See comparisons here:

If we add new languages - potential strategy

Instead on relying on GH pages engine, we could use this action to run the build: https://github.com/dieghernan/RKI-Corona-Atlas/blob/master/.github/workflows/build-gh-pages.yml. This won't cause any timeout issues, but there are two caveats:

• The action should be run after the scrapping action asynchronously. Now it is set to run on cron on 5:15, 11:15, 17:15... i.e. 15 minutes after the scrapping data.
• GH Pages should be build from gh-pages branch. See https://github.com/dieghernan/RKI-Corona-Atlas/tree/gh-pages, containing the raw html code that is the result of the process.

Conclusion

Now we are still on "old" strategy (GH engine) with lower boundary resolution, and page build is coming from master branch.

If we want to move to the new strategy (new languages, more resolution on maps, page from gh-pages branch) I can make it work, but expect some delay between scrapping and page update. For your information, the action https://github.com/dieghernan/RKI-Corona-Atlas/blob/master/.github/workflows/build-gh-pages.yml is currently disabled as we are still in "old" mode.

[dieghernan]

@rodrihgh I added the new languages to the navbar, feel free to amend/modify/improve

[rodrihgh]

Thank you for taking the time to tackle the issue. However, I think the current state is too involved, so I have quarantined the French and Polish languages. You are welcome to roll back everything else on your side, too. @dieghernan

Let me make an alternative suggestion...

[rodrihgh]

I would strongly prefer a solution where we do not duplicate the same map with every new language. As a matter of fact, we are using the same polygons with different text, so I think we should try a different approach:

1. We build just one map (maybe two just in case we want to keep the more complex German text separated) as a standalone block.
2. We include the map in an "iframe-esque" way into every page (not 100% sure if iframes are the best technical solution)
3. We adapt the text to the corresponding language over the top. I have a gut feeling that the internationalization plugin for Leaflet should allow to do that: https://github.com/yohanboniface/Leaflet.i18n

It is still unclear how to work with the said plugin, e.g. whether translations should happen at "nuclear" level (country names, dates, idioms...) or "block" level (information blocks per country). If we cannot make the plugin work, I would still prefer to keep the "iframe" approach with English information in ES, FR, PL & Co.

If you like this idea, I will take a look at the plugin and see what it can do.

[rodrihgh]

Just an example of internationalization in the wild:

https://github.com/Raruto/leaflet-elevation/blob/a9f2c2a6230d8bfb55bbe12d7eae3a45845cfaa4/examples/leaflet-elevation_i18n-strings.html#L40-L67

https://raruto.github.io/leaflet-elevation/examples/leaflet-elevation_i18n-strings.html

[rodrihgh]

I have worked out a page that loads GeoJSON on Javascript and glues it together with the corresponding risk colors and labels. I have taken the code from Raruto's repo above, so the styling does not look like ours yet:

@dieghernan I would let you style the map as you want on the Javascript code (you may also need to change the scripts on the header, too:

https://github.com/dieghernan/RKI-Corona-Atlas/blob/772041c3e9d386158d4802425a9c9ecc5d837c28/assets/html/load_geojson.html#L48-L105

Once you are done, I can insert the map in all the different pages with the corresponding text.

[rodrihgh]

Done!

For you to know how things now are done:

• The scraper directly produces all the databases in the different languages
• It also produces risk.js, with a JSON object containing the risk level codes of all countries, and locale_*.js with the information in the different languages.
• The polygons are taken from assets/geo/country_shapes.geojson
• db_scraped.csv drops the information in German
• The interactive tables are still generated in R