Feature/basic i18n

[Greenheart]

fixes #345
fixes #444

Now ready for review.

Main changes

• Introduce next-i18next (based on i18next) to handle translations
  • Split content into multiple namespaces to allow only loading what is needed for each route.
  • Refactor code to separate dataset keys from the UI labels, to allow translations.
  • Allow translating datasets
  • Refactor to separate dataset keys from the UI strings used to describe them. For example, use utslappen as key (to align with the existing URL structure that we need to support), instead of Utsläppen. This makes it easier to separate code and logic from content.
  • Add support for translating content outside of the Next.js/React context (see utils/getServerSideI18n.ts for more details)
• Add Markdown component based on react-markdown, to allow formatting links, bold, italic, and lists via translated content rather than hard coded in JSX.
• Delete tests for the footer, since they were only testing content rendering and not functionality.
• Update tests to work with translated content. Now testing for translation keys rather than hard coded content. In the future, we should prefer tests for functionality.

Minor fixes and changes

• Use HTML details element to make ScorecardSection accessible and easier to use (for example with keyboard).
• Fix error in Next.js API routes and remove warning from dev console.
• Add StyleSheetManager from styled-components to only render valid HTML attributes to the DOM.
• Add missing <thead> to fix React error
• Simplify DropDown component to remove unused classes.
• Fix some formatting errors in styled-components CSS blocks.
• Improved UX by making it possible to close <InfoModal> by clicking on the backdrop.
• Simplify code for <InfoModal> in MunicipalityEmissionGraph.tsx
• Add missing key attributes to fix react rendering errors
• Minor styling tweaks to fix layout issues (for example CementClarification) on the method page, and the grid on the about page.
• Replace deprecated method String#substr with String#slice
• Fix some instances of next/image to use modern config and styling.
• Remove unused Navigation.tsx which seems to have been left over in some refactoring.
• Remove unused Range.tsx component
• Remove unused LoadingContainer from components/shared.tsx
• Remove unused Vercel SVG

---

Notes

• The need to provide translations to every Next.js page can be tricky. However, this will not be a problem if/when we migrate to the Next.js app router, since we then will be able to specify the props (like translations) for the root layout, only adding the more specific props (like translations) for child routes. Since the app router will allow us to avoid this issue, I thus opted to prepare for i18n namespaces now while we're at it.

• For more details from the process of working on this, please see Add support for basic i18n: refactor strings to separate content from code #345 (comment)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
klimatkollen	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 23, 2024 3:40pm

[Greenheart]

All previous comments have been resolved. Now ready for further review 🙂

---

NOTE: The following was tested with DEV and comparing to PROD, which has some obvious differences in performance.

I just found another potential issue that is introduced with this PR: listColumns() is called many more times than before. This is because we can't use the constant dataDescriptions, and instead need to get the translated version via getDataDescriptions(), which probably cause extra re-renders.

One good thing is that we do have some caching, which greatly speeds things up. But it is still significantly slower than before. To some extent, this is expected since translations require much more work compared to hardcoded strings. But if we think it is too big of a performance difference, we might want to introduce a few useMemo() calls to try to reduce re-renders.

---

Sidenote: when debugging this, it became clear that the dataset definitions have many responsibilities. Either they should have all rendering logic (like which field to display, and how to format it), or we separate this. But let's not do that now.