Get rid of react-i18n

[SachaG]

Get rid of react-i18n

[eric-burel]

You mean "@devographics/react-i18n" (which is mostly used by surveyform so could be internalized) or "i18next" ? I've just cleaned old unused dependencies in the dev branch towards i18next, we no longer use any of this.

[SachaG]

I think I meant @devographics/react-i18n ? The issues if I recall correctly are that:

1. The current system in surveyform which copies react-i18n forces us to use an API that doesn't really match our data model (for example it doesn't include metadata such as html/clean versions, isFallback, etc.)
2. results has its own version of FormattedMessage, intl.formatMessage(), etc. instead of sharing with surveyform

So we should probably extract the i18n stuff from results and then reuse that in surveyform as well.

[eric-burel]

I've started the first step, extracting i18n from "results" and marking the surveyform version as deprecated

[eric-burel]

Data fetching logic is quite different, I've found results logic but the first step is to move it to TS to have a better grasp of the data structures, I've started the migration

[eric-burel]

To keep track of our discussion, the tricky part in our setup is that our i18n tokens are semi-dynamic, they depend on contextual values like the current survey: html2023.foobar. But hopefully these values are not really dynamic, in the sense that they can be known at build-time. So we can have an optimal system that injects exactly the right tokens client-side, in theory.

Target architecture for optimal injection of tokens:

• components declare what they need using a token expression language. It needs to cover contextual values, and range values. For instance {{surveyId}}.foobar would be interpreted as html2023.foobar if the current survey is HTML 2023, and options.[[all_questions_id]] would be interpreted as the list [options.question1, options.question2] where "question1", "question2" are questions found in the current page sections
• when rendering the page, we filter all the tokens to get only the relevant one, might be a tad costly in computations when doing dynamic rendering but it's ok for static rendering

This way pages only ever get the tokens they need. Note that this problem doesn't exist much for true server components, because the list of all tokens never reaches client-side. This is only a problem for client-side rendered components, that needs to access tokens.