Univention Bugzilla – Bug 38370
UMC: Mixture of german and english under particular circumstances
Last modified: 2017-04-04 18:28:44 CEST
Created attachment 6857 [details] Screenshot with mixed languages It is possible to receive parts of the UMC with english text and at the same time other parts with german text. I've seen this twice during workshops, but unfortunately wasn't able to track it down, yet. I guess this is the result of some combination of language settings on the client OS, client Browser, in the UMC, user agent ... Reload with CTRL + SHIFT + R (overriding browser cache) did not help. Screenshot attached, where ... - Windows is german - Firefox is german - UMC language selection is german - text is partly german and partly english
The reason is that there still exists a english running module process. Pressing F5 will not create a new session. Workaround is doing a real logout. I don't know if we should fix anything here.
I see two possible explanations for this behaviour: (a) By opening a second tab, the locale which is used for the current user session in the backend is changed. Consecutive requests from a previous tab (in the "old" locale) will then respond in the new locale. (b) If locale (and locale/default) are set to EN_US.UTF-8 and the default browser locale is detected as German, it might be that DE_DE is set as locale, although the backend only supports EN_US. As the German translations files for the frontend are there, these will be used by JavaScript nevertheless.
See Bug 38129, comment 5: > Hm... not really. I still experience this problem (on 2 different VMs). We > observed that we have different locales on our VMs, Florian (as you did not > observe this problem): > > locale/default: de_DE.UTF-8:UTF-8 > locale: de_DE.UTF-8:UTF-8 en_US.UTF-8:UTF-8 > > Curiously, the /proc/XYZ/environ file contains: LANG=de_DE.UTF-8
(In reply to Alexander Kläser from comment #3) > [...] > > Curiously, the /proc/XYZ/environ file contains: LANG=de_DE.UTF-8 I.e., XYZ is the PID of the appcenter UMC module process.
+1 ... this problem has also been seen during a technical training.
(In reply to Alexander Kläser from comment #5) > +1 ... this problem has also been seen during a technical training. Happened after a fresh installation of UCS.
(In reply to Alexander Kläser from comment #6) > Happened after a fresh installation of UCS. + 1 today in another technical training.
In UCS 4.1 a explicit "set locale" is done on each authentication or session-login. On UCS 4.0-3 this can be reproduced by opening the udm users/user "Add" wizard and replace the query string parameter ?lang=de-DE to ?lang=en-US. The "set locale" call is not reached down through the running UMC module processes. We could do this as well (REOPEN the bug then).
Hm, it just occurred during product tests: I installed a app and ignored the "reload page" instruction. After this I had mixed translations. A page reload didn't help. App descriptions on the overview are german. All others are translated correctly. The UDM javascript translations are fine but the backend translations are all german.
Created attachment 7278 [details] patch for problem 2 1. univention.lib.i18n.Translation is something like a singleton which uses the same locale for every instance. A process (like UMC) which uses multiple instances of it with different languages can't use it then. 2. The language of the running module processes is not changed when the language gets changed (e.g. by page reload). 3. The locale is reset when importing/reloading syntax.py (due to Bug #39146).
Created attachment 7621 [details] patch Got a reproducible way: # ucr dump | grep locale locale/default: de_DE.UTF-8:UTF-8 locale: de_DE.UTF-8:UTF-8 en_US.UTF-8:UTF-8 On a german system in an english session ?lang=en-US the following JS code will cause that the session will be reset to german. umc.tools.renewSession().then(function() { umc.app.reloadModules(); } Attached is a patch.
*** Bug 42154 has been marked as a duplicate of this bug. ***
Done in combination with Bug #38370. The "Accept-Language" header is passed along with each request to the server and module proccesses. The session will use the new language if it changed. HTTP requests which don't come from our Javascript framework don't cause an language update e.g. so that the language is not updated by the browser wide setting when receiving a computerroom/screenshot. univention-web (1.0.8-6): r76194 | Bug #40612: jshint coding style r76161 | Bug #40612: Add language switch to the menu bar r76132 | Bug #40612: set authentication via HTTP header during login univention-management-console (9.0.21-2): r76335 | Bug #40612: Bug #38370: fix updating of language r76160 | Bug #40612: Add language switch to the menu bar r76134 | Bug #40612: Bug #38370: fix language mix after e.g. installing a app r76133 | Bug #40612: set authentication via HTTP header during login univention-lib (6.0.6-7): r76335 | Bug #40612: Bug #38370: fix updating of language
As discussed, there is still some mixture between languages when choosing in the menu "Change language". We will need to stop the session module processes in order to be able to restart the module processes with the new language. However, this should only be done if the change language request is triggered from within UMC ... just to avoid side effects with running module processes when changing the language, e.g., from within the portal.
univention-web (1.0.22-1): r76688 | Bug #38370: renew session before switching language in UMC
Changes: OK, works as discussed Changelog: OK → VERIFIED
UCS 4.2 has been released: https://docs.software-univention.de/release-notes-4.2-0-en.html https://docs.software-univention.de/release-notes-4.2-0-de.html If this error occurs again, please use "Clone This Bug".