Add support for basic i18n: refactor strings to separate content from code

[LudwikJaniuk]

User-facing text strings are currently spread out all over the codebase. It would be nice to be able to translate klimatkollen to e.g. English - but as a first step, the strings need to be brought together into a single file/class that it is possible to replace.

[Greenheart]

Working on this since yesterday. Draft PR hopefully ready soon :)

First steps for translated content

• [x] Setup translation solution that works well with Next.js, so the UI can be rendered immediately on the client, rather than fetching translations client side.

• [x] Question: How to handle strings from data sets? Doesn't matter now when we have one language, but it will in the future. Decision (12/4): Extract dataset content into translation files. Use Markdown to support complex formatting with minimal development effort, moving the complexity to the markdown formatting itself. In the future, we might want a CMS and a more efficient data structure, but for now, Markdown is a very simple and effective start.

• [x] Question: How to handle Footer tests that break due to testing the phrasings of translated content. Might be worth removing those tests if they don't add much value, and keep the tests focused on features rather than rendering. Yes, we remove them for now.

• [x] Question: How to handle the /in-english vs /om-oss routes? It could be possible to add dual languages for just those routes, and use Next.js i18n routing to map different locales to different URLs. However, it might be worth keeping it simple and just adding everything to the sv locale for now. Especially since a big redesign is coming up. Decision: Let's skip the /in-english page for now, since that doesn't make sense to add to the sv locale. Instead, we decide how we want to design the about page, and then translate that into both sv + en when it is ready.

• [x] Consider extracting links too, since they could be nice to edit via a future potential CMS, rather than hardcoded in the code. Links in hard JSX content can now be converted to markdown strings, while still adding the expected HTML attributes for external links via the plugin rehype-external-links.

• [x] Extract all strings that can easily be translated. This includes pages, but also other code that uses localized strings.

• [x] Ensure we use namespaces in a consistent way. Prefer namespace:some.translation.key with the : to clearly separate keys from namespaces.

• [x] Skip content that uses complex formatting. Links, combined strings and more. This might be better to translate via a CMS.

  • datasetDefinitions.tsx is one such example, which will require some refactoring. I documented what needs to be changed while evaluating if this would be viable, and determined this refactoring should be left for a future, separate PR.

[LudwikJaniuk]

I think when I created this issue I only thought of this part:

Extract all strings that can easily be translated. This includes pages, but also other code that uses localized strings.

But these are all important considerations for making a good translations. Feel free to edit the title if you intend to work towards the larger scope of a full-on internationalization within this ticket.