Add i18n support

[Bachibouzouk]

We should look for solution to separate the languages in a clean way. This issue is not urgent.

[nesnoj]

i18n is supported by django and should be used in the WAM. The required middleware was enabled in #80.
It is currently tested and implemented in StEmp ABW by @4lm, cf. rl-institut/WAM_APP_stemp_abw#72. As soon as this works, we can use it as a blueprint for the WAM.

[4lm]

Hi all,

we implemented i18n in stemp_abw and it works. But there seems to be a drawback. We have to define a default language via the constant LANGUAGE_CODE, which lives in wam.settings. We define this constant in our app specific settings.py (see this commit: rl-institut/WAM_APP_stemp_abw@da72dd9), which is imported as global project setting for all apps by a routine in wam/settings.py (https://github.com/rl-institut/WAM/blob/dev/wam/settings.py#L184-L206).

The problem I have with this solution is, that:

• if two apps define a different default language in their app specific settings.py, the later imported app setting will overwrite the imported setting that came first.
• if an app defines a default language, that is not present in another app, than i18n will not properly work in that i18n.

Has anyone an idea how to fix this? This problem occurs, because we don't use a Django project base (WAM) for every app, instead we try to share one WAM with all apps (IMO we use Django differently as intended).

I assigned the whole dev team to this issue, because I also want to take this issue as opportunity to talk about our strategy in general (shared Django project base vs Django project base for each app). Maybe in another issue or in a short meeting.

What do you think?

[4lm]

to talk about our strategy in general ... Maybe in another issue ...

#74 seems to be a good place

[nesnoj]

Yes, this is a critical problem indeed. A major restructuring as you proposed is a clean solution but this raises heaps of other questions and, most important, we would need a lot of time...

if two apps define a different default language in their app specific settings.py, the later imported app setting will overwrite the imported setting that came first.

a) Instead of setting a default language in the app-specific settings.py, we agree on a WAM-wide default language (DE or EN) which must be supported by all(!) apps. (the setting of the default language in an app should be omitted automatically)

if an app defines a default language, that is not present in another app, than i18n will not properly work in that i18n.

b) Wait, I thought if the app does not support the current language set in your session/cookie, it falls back to default?! If so, it should be enough to set the WAM-wide default language, right?

What I don't know is whether the fallback in b) resets the language code in your cookie. Yes, no?
If not, this could be done manually in get_session()

What do you think?

By the way, this is related to the interference of app settings in general #74

[nesnoj]

@4lm, we decided for 'de-DE' as default language, as u can see in the commits above I adjusted WAM & StEmp ABW accordingly. Seems to work 👍.
Anything I overlooked?

EDIT: See also: rl-institut/WAM_APP_stemp_abw#72 (comment)

[nesnoj]

Ok, i18n is working now.
This issue should be kept open until there's a general i18n support for wam pages (e.g. utils -> feedback form).