Switch to an internationalization strategy and decouple technical writings from implementation

[BarcoMasile]

Description

Right now the codebase (both frontend and backend) uses string constants or inline strings for displayed text, Error messages are also implemented in the same way.

This causes the birth of issues deriving from the lack of a centralized place to handle all authored content by either our technical writers or our ux designers.
Lack of centralized control over contents also causes a lack of uniformity in displayed text since some words may appear spelled or capitalized in a different way based on who wrote the code, since it is not easy to go through the whole codebase and look for the preferred way to present some text.

Having a centralized file (or set of files) will allow us to work way more efficiently when it comes to interaction with technical authors and designers.

I'm writing this with these issues in mind since in the recent months we've been having issues like these, but we should not forget that solving this problem also allows us to introduce ("for free") translation support infra we will need when the company asks us to add real internationalization support.

Proposed solution

My proposed solution is to:

• adopt the react-i18next library to leverage the useTranslation hook throughout the frontend code
• centralize the string contents of the whole app in a single file (or a set of files, but one file is a great starting point), it's easier than it sounds like, speaking from experience
• remove string constants from the codebase and switch to the corresponding translation keys

First main basic implementation in the frontend

To start things off right, we would only need to add this to the frontend code

import enStrings from '../../locales/en/strings.json' // single file with the string contents for the app

i18n.use(initReactI18next).init({
  resources:  {
    en: {
      translation: enStrings,
    },
  },
  lng: 'en',
  react: {
    transKeepBasicHtmlNodesFor: ['br', 'strong', 'i', 'code', 'p'],
  },
})

and then in App.tsx use the React context provider:

  <I18nextProvider i18n={i18n}></I18nextProvider>

Pros

• string constants can be moved over to the i18n infra incrementally after the first main implementation in the frontend code (see above)
• technical authors and UX designers would have full indipendence in refactoring strings or introducing new ones so their contribution would speed up things without causing conflicts with the rest of the dev team PRs
• last but not least, we open the door for internationalization

Cons

• needs a little effort to move contents over to the new structure, but as said, it does not have to be done in one pass, it can be done iteratively or opportunistically

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/IAM-1263.

This message was autogenerated

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/IAM-1264.

This message was autogenerated

[BarcoMasile]

@lukasSerelis @edlerd @mas-who

[edlerd]

I think a translation layer adds a lot of complexity, and we should only pull in that extra complexity if we have to.

Also, we don't have a list of all text used in the app. Because a lot of copy is coming from the API. For instance, node labels or error messages are not owned directly by the UI code.

I suggest pushing this to a point in the future, where we want to start supporting i18n with more than one language.