1623: Add i18n for administration

[ztefanie]

Short description

Move labels from objects in the database to translation.json

Proposed changes

• Added i18n to administration
• Use labels from translation file instead of database/object-json
• remove adding labels before saving new application to the database

Side effects

• May break everything especially things related to applications

Testing

• Open application for /beantragen and check if all labels for all cases are displayed properly
• create applications for different type, e.g. blue entitlement card for work at organization, julica, ... and view if all labels are correctly displayed in the digitale druckerei "Eingehende Anträge" view.
• check if older applications created without these changes here are still displayed properly
• check if sent emails still look as expected

Todo for follow up ticket

• replace all german strings with labels from translation file

Resolved issues

Fixes: #1623

[f1sh1918]

For the applications i would store the i18n labels in the json structure and resolve them in the frontend instead of saving the particular values (as it is now). i don't see the whole database redesign in this verein360 project to be honest even it will be a bit ugly to reconstruct the application data json after receiving the data from the verein360 endpoint. I think we need proper tests for this reconstructing function.
I think we may extract the personal data (that will be more or less the same for all projects) at a later point and only store application depending data in the json format if we also want to maintain and store user data for long term.
Its even not sure if frankfurt will come and at the moment its not clear if we then need additional functionality which can not be provided with the current (json) solution.

The initial i18n implementation looks fine to me

[steffenkleinle]

Is there any reason you did not stick to the format/structure we use in integreat, i.e. using one file to store translations for all languages? That way, we could reuse existing tools and scripts and therefore our whole translation process.

One other question: Do you know why it is not necessary anymore to wrap the app in a I18nProvider or similar? Is that just an unnecessary thing we do in Integreat or it became obsolete with some update in the past?

Otherwise, no objections from my side.

[ztefanie]

Thanks for your feedback.

@steffenkleinle

Is there any reason you did not stick to the format/structure we use in integreat, i.e. using one file to store translations for all languages? That way, we could reuse existing tools and scripts and therefore our whole translation process.

Valid question. I thought about this, too and decided to stick to the solutions described in the documentation rather then to the integreat solution. The reasons for this is the integreat solution is a lot complexer, e.g. needing functions to merge the language documents into one translation file. This makes sense for integreat where we have this whole import / export translations logic, but not really for entitlement card furthermore the out of the box functionality of i18next is absolutely sufficient for the use cases of the entitlementcard and needs no enhancements like we use in integreat.

One other question: Do you know why it is not necessary anymore to wrap the app in a I18nProvider or similar? Is that just an unnecessary thing we do in Integreat or it became obsolete with some update in the past?

The I18nextProvider does take an i18next instance and passes that down using contexts. As we do not consume the translations for context, but by using the useTranslation() hook, it is not needed. I am not quite sure, if we still have occurences in Integreat where we use translations from context, if not, it should be save to delete this Provider.

[steffenkleinle]

Thanks a lot for the work on this tedious issue 🙏 Looks pretty good already :)

[steffenkleinle]

Smoke tested on firefox, looks good :)

[f1sh1918]

Looks good. One finding telephone label is missing in translations file

[ztefanie]

Looks good. One finding telephone label is missing in translations file

Thanks for testing. Please approve if only small things needs fixing. Also maybe you do not want to publish your adress and phonenumber on github?