Add i18n internationalization support

[blankdots]

Description

Add internationalization support using https://react.i18next.com/ (or similar) for Finnish and English.

DoD (Definition of Done)

UI is able to switch between language seamlessly.
There is a dropdown that allows language switching in the menu bar

Testing

Peer review (for now)

[otahontas]

Regarding internalization for forms, we can do translations for different schemas like study_fi.json / study_sv.json with titles and descriptions for each field. Then on frontend study_fi.json is should be appended to study.json, so all titles / descriptions from study.json are overridden.

[otahontas]

For form errors we should use https://github.com/ajv-validator/ajv-i18n. It doesn't (currently) have finnish translations, so they should be probably created by csc

[blankdots]

we need to be able to remember the language selection in the route (url)

[saulipurhonen]

About translating forms I see at least two options:

1. Have translated schemas ready in the backend and this way reduce computing on client side
2. Client translates the schema on fetch. Translated schema can be stored in session storage along with original schema

[blankdots]

About translating forms I see at least two options:

1. Have translated schemas ready in the backend and this way reduce computing on client side
2. Client translates the schema on fetch. Translated schema can be stored in session storage along with original schema

option 1 sounds ok, however is there an option that we can also have them in front-end as assets?

e.g. in another project we store them as: https://github.com/CSCfi/swift-browser-ui/blob/master/swift_browser_ui_frontend/src/common/lang.js or this is equivalent with option 2?

[saulipurhonen]

option 1 sounds ok, however is there an option that we can also have them in front-end as assets?

e.g. in another project we store them as: https://github.com/CSCfi/swift-browser-ui/blob/master/swift_browser_ui_frontend/src/common/lang.js or this is equivalent with option 2?

This is basically equivalent. We'd need to traverse original schema and return a schema with matching translations from assets. This action don't benefit from i18next library.

One another option could be translating fields on the fly with i18next library but I think it is a bad idea since form might re-render on different occasions causing unnecessary load on client.

Workload wise I think the option shouldn't matter much. Only concern is frontend performance

[blankdots]

ok, i will add something for that in backend

[blankdots]

closing as this is going to be continued in the issues #489 and #490