Description
User statement
As a future user, I would (maybe) like to enjoy a translated application.
As a current coder, I want to be able to store translation strings in a robust manner.
Background
Currently, all of our translation strings are stored in custom objects colocated with a component. As discussed in FE variety, we are pivoting to use a library to handle translations. There are numerous reasons for this (see the Notion doc) but some of big ones are:
Right now, sometimes we break up strings in ways that aren’t actually conducive to future translation; a library would help with that
Currently, if a developer refactors up a Language object, it is unclear which strings are not in use. Switching to a library will help us avoid stale strings
Sometimes we store business state in our Language objects. This is an anti-pattern that a library would help us avoid.
Definition of Done
- Add react-i18next to our Front End.
- Add at least one translation file as proof-of-concept so that it's easy for others to get started with translations when they make new PRs or refactor old code.
- There is no need to migrate all Language blocks over right now. This can be an incremental change that we make going forward.
- Ensure all tests are passing.