Fri, 10 Apr 2026 09:04:29 +0000 https://bugs.horde.org/ticket/9437 Language selection at login fails $conf['auth']['driver'] = 'application'; $conf['auth']['params']['app'] = 'imp'; I use Firefox 3.6.12 about:config => intl.accept_languages = "fr, fr-fr,en-us, en" No matter what language I select, Horde always log me in using the French language. If I change Firefox 's setting to intl.accept_languages = "en-us, en,fr, fr-fr", Horde will always appear in english. Wed, 08 Dec 2010 13:21:10 +0000 https://bugs.horde.org/ticket/9437#t61035 Michael just fixed a bunch of issues with language selection in the login screen. Does this fix your problem? Mon, 20 Dec 2010 23:30:23 +0000 https://bugs.horde.org/ticket/9437#t61131 Changes have been made in Git for this ticket: Bug #9437: Fix language selection via login screen http://git.horde.org/horde-git/-/commit/f8eb4531db2bacffbff430b8774e1fb16350cd2e Tue, 21 Dec 2010 22:13:24 +0000 https://bugs.horde.org/ticket/9437#t61149 No - this was an issue with the Registry auth code where we were always calling setLanguageEnvironment() after set the authentication credentials with the value of the user's language preference. Instead, we want to grab the language information from the non-authenticated session and set to this value (if possible) in order to match the login screen. Tue, 21 Dec 2010 22:20:17 +0000 https://bugs.horde.org/ticket/9437#t61150 > Changes have been made in Git for this ticket: > > Bug #9437: Fix language selection via login screen > > http://git.horde.org/horde-git/-/commit/f8eb4531db2bacffbff430b8774e1fb16350cd2e I'm still having this issue. Need a trace ? Where can I look ? Wed, 22 Dec 2010 08:07:44 +0000 https://bugs.horde.org/ticket/9437#t61156 > I'm still having this issue. > Need a trace ? Where can I look ? Look at Horde_Registry::preferredLang() - it should reach the second if clause if it is working properly. Wed, 22 Dec 2010 08:51:16 +0000 https://bugs.horde.org/ticket/9437#t61159 Changes have been made in Git for this ticket: Ticket #9437: Tweak preferred language selection. I *think* this should be the behavior (precedence-wise): Pre-auth -------- Prefs will most likely be unavailable or default language is empty. Language will be set based on language drop-down on login refresh (if language switching allowed) Session language is used (pre-auth session will have language set if the login screen has been reloaded) System-wide default used (nls config) Finally, browser detection. Post-auth --------- Value in user's prefs will ALWAYS control (regardless of login screen language selection) Language from login screen will be used (if language switching allowed) On initial login session is new/clean; language info unavailable here On subsequent login, this contains the session language (code will ALWAYS stop here after user is authenticated) System-wide default used (nls config) Finally, browser detection. http://git.horde.org/horde-git/-/commit/f3e1f1c153b3c70a21748bba366e81a1a1dfe594 Wed, 22 Dec 2010 18:07:56 +0000 https://bugs.horde.org/ticket/9437#t61166 I've tweaked the code some more, so try now. Note that the login language selection will NEVER work if the user has a 'language' prefs value set. Wed, 22 Dec 2010 18:10:25 +0000 https://bugs.horde.org/ticket/9437#t61169 That's not quite correct. > Pre-auth > -------- > > Prefs will most likely be unavailable or default language is empty. > Language will be set based on language drop-down on login refresh (if > language switching allowed) > Session language is used (pre-auth session will have language set if the > login screen has been reloaded) > System-wide default used (nls config) > Finally, browser detection. That should be: 1. Default preference, if locked. 2. Language will be set based on language drop-down on login refresh (if language switching allowed) 3. Session language is used (pre-auth session will have language set if the login screen has been reloaded) 4. Finally, browser detection. 5. System-wide default used (nls config) > Post-auth > --------- > > Value in user's prefs will ALWAYS control (regardless of login screen > language selection) > Language from login screen will be used (if language switching allowed) > On initial login session is new/clean; language info unavailable here > On subsequent login, this contains the session language (code will > ALWAYS stop here after user is authenticated) > System-wide default used (nls config) > Finally, browser detection. 1. Value in user's prefs will ALWAYS control (regardless of login screen language selection) 2. Language from login screen will be used (if language switching allowed) On initial login session is new/clean; language info unavailable here On subsequent login, this contains the session language (code will ALWAYS stop here after user is authenticated) 3. Finally, browser detection. 4. System-wide default used (nls config) Wed, 22 Dec 2010 18:43:59 +0000 https://bugs.horde.org/ticket/9437#t61170 You want nlsconfig to be last (below browser detection)? I have no problems with that, except that this is the way it has been forever (at least in H3). I do have an issue with this though: > 1. Default preference, if locked. (pre-auth) Why does it make a difference if it is locked? A preference value is a preference value. Its locked status does not change the value; locking only influences whether the preference value can be *changed*. When determining the preferred language, if there is a value set for the 'language' preference, whether it is locked or not or whether it is the default user or an actual user, it doesn't matter. All that matters is that a value exists and it is not blank (previously, this was broken - if the preference was locked but set to blank, we would skip all other determinations and default to en_US which is surely not what is wanted). For example, an admin could set a default language in the prefs, but keep it unlocked, and a guest user could theoretically go in and change this value in the prefs. The default value should be used until that happens though - it shouldn't be ignored. Wed, 22 Dec 2010 19:06:55 +0000 https://bugs.horde.org/ticket/9437#t61171 > I've tweaked the code some more, so try now. > > Note that the login language selection will NEVER work if the user > has a 'language' prefs value set. still not working. I deleted prefs and cache before trying. I'll try to look at Horde_Registry::preferredLang() Thu, 23 Dec 2010 08:21:49 +0000 https://bugs.horde.org/ticket/9437#t61176 public function preferredLang($lang = null) I always get to : return basename($GLOBALS['session']->get('horde', 'language')) => fr_FR $lang is always null/empty. Calls to function preferredLang don't have any argument. That's probably why $lang is always empty. #grep preferredLang -r /var/www/html/horde libs/Horde/Registry.php: public function preferredLang($lang = null) libs/Horde/Registry.php: $lang = $this->preferredLang(); libs/Horde/Core/Ui/Language.php: $session->set('horde', 'language', $registry->preferredLang()); libs/Horde/Core/Auth/Application.php: $language = $registry->preferredLang(); services/language.php:$session->set('horde', 'language', $registry->preferredLanguage(Horde_Util::getForm('new_lang'))); Thu, 23 Dec 2010 08:40:49 +0000 https://bugs.horde.org/ticket/9437#t61177 > public function preferredLang($lang = null) > > I always get to : return basename($GLOBALS['session']->get('horde', > 'language')) => fr_FR You are not catching the call on login properly; the session is destroyed when logging in so this value MUST be empty. This value is initially set in Horde_Registry::setLanguage() (line 2234) so maybe you should check there. Thu, 23 Dec 2010 08:48:49 +0000 https://bugs.horde.org/ticket/9437#t61178 Changes have been made in Git for this ticket: Bug #9437: Last fallback should be nlsconfig default language http://git.horde.org/horde-git/-/commit/c38ad90cc7788025f6e7a42e1d06bb5b36574d62 Thu, 23 Dec 2010 10:28:10 +0000 https://bugs.horde.org/ticket/9437#t61179 > You want nlsconfig to be last (below browser detection)? I have no > problems with that, except that this is the way it has been forever > (at least in H3). What? nlsconfig to be the last? Yes, at least I tried to keep the list in the same order like we have in Horde 3. > I do have an issue with this though: > >> 1. Default preference, if locked. (pre-auth) > > Why does it make a difference if it is locked? A preference value is > a preference value. Its locked status does not change the value; This was the only way in Horde 3 to force the interface to a certain language. If we have a different way now to do this that doesn't stretch the semantic of a locked preference, even better. > locking only influences whether the preference value can be > *changed*. When determining the preferred language, if there is a > value set for the 'language' preference, whether it is locked or not > or whether it is the default user or an actual user, it doesn't > matter. All that matters is that a value exists and it is not blank > (previously, this was broken - if the preference was locked but set > to blank, we would skip all other determinations and default to en_US > which is surely not what is wanted). > > For example, an admin could set a default language in the prefs, but > keep it unlocked, and a guest user could theoretically go in and > change this value in the prefs. The default value should be used > until that happens though - it shouldn't be ignored. I disagree, at least if I understand you correctly. The language selection in the login screen and the browser's preferred language should have precedence over the default preference value, that's what we did in H3. Though now that I think about it, this would be the only way an admin could set a default language for all users without having to lock it at the same time. Thu, 23 Dec 2010 11:06:47 +0000 https://bugs.horde.org/ticket/9437#t61182 I re-cleared FF's cache and *cookies*, and now it is working. Thanks. Thu, 23 Dec 2010 11:59:24 +0000 https://bugs.horde.org/ticket/9437#t61184 > I re-cleared FF's cache and *cookies*, and now it is working. In fact, it doesn't always work. If fields username and password are empty when changing language => OK. If either username or password isn't empty => NOK. Thu, 23 Dec 2010 12:05:23 +0000 https://bugs.horde.org/ticket/9437#t61185 > If fields username and password are empty when changing language => OK. > If either username or password isn't empty => NOK. It always worked this way. We don't want to prefill the password field when reloading the page, and we don't want to lose the entered credentials either. Thu, 23 Dec 2010 13:06:56 +0000 https://bugs.horde.org/ticket/9437#t61186 > It always worked this way. We don't want to prefill the password > field when reloading the page, and we don't want to lose the entered > credentials either. I understand, but the login script should be able to use the selected language, even if the page hasn't been reloaded. I haven't looked at the code, but it looks like the login process only look for/use variable 'new_lang' set in $_GET and not $_POST. But the login form uses method POST. Thu, 23 Dec 2010 13:35:14 +0000 https://bugs.horde.org/ticket/9437#t61190 > I haven't looked at the code, but it looks like the login process > only look for/use variable 'new_lang' set in $_GET and not $_POST. > But the login form uses method POST. Yes - this is the case. And I agree that the language should be changed regardless of the GET/POST status. e.g you switch language and try to login unsuccessfully - when the login screen reloads, the language should be switched. Thu, 23 Dec 2010 18:50:36 +0000 https://bugs.horde.org/ticket/9437#t61196 Changes have been made in Git for this ticket: Bug #9437: Change language regardless of POST/GET http://git.horde.org/horde-git/-/commit/893cb996233774ceec8499844c6f8d973a210ef7 Thu, 23 Dec 2010 18:50:38 +0000 https://bugs.horde.org/ticket/9437#t61197 >> You want nlsconfig to be last (below browser detection)? I have no >> problems with that, except that this is the way it has been forever >> (at least in H3). > > What? nlsconfig to be the last? Yes, at least I tried to keep the > list in the same order like we have in Horde 3. In Horde 3 the check for $nls['defaults'] occurs before the check for HTTP_ACCEPT_LANGUAGE. At least in NLS::select(). >> I do have an issue with this though: >> >>> 1. Default preference, if locked. (pre-auth) >> >> Why does it make a difference if it is locked? A preference value is >> a preference value. Its locked status does not change the value; > > This was the only way in Horde 3 to force the interface to a certain > language. If we have a different way now to do this that doesn't > stretch the semantic of a locked preference, even better. I just don't see why isLocked() is necessary in Horde_Registry::preferredLang() is all. I support the idea that locking the preference prevents language changing, but that should be handled in the login UI. > I disagree, at least if I understand you correctly. The language > selection in the login screen and the browser's preferred language > should have precedence over the default preference value, that's what > we did in H3. > Though now that I think about it, this would be the only way an admin > could set a default language for all users without having to lock it > at the same time. Then what's the point of the 'language' preference? And maybe I'm reading you wrong, but the login screen language (or browser detection) is used as the language as long as the 'language' preference is empty. But once the 'language' preference is filled with a language, to me that is indication by the admin/user that this is the canonical language to use, despite the login screen indication. And we can't hide the language selection on login based on this value since we don't know what that value is for any given user. Thu, 23 Dec 2010 19:12:54 +0000 https://bugs.horde.org/ticket/9437#t61199 >>> You want nlsconfig to be last (below browser detection)? I have no >>> problems with that, except that this is the way it has been forever >>> (at least in H3). >> >> What? nlsconfig to be the last? Yes, at least I tried to keep the >> list in the same order like we have in Horde 3. > > In Horde 3 the check for $nls['defaults'] occurs before the check for > HTTP_ACCEPT_LANGUAGE. At least in NLS::select(). Yeah, look like was wrong. Probably because it is empty by default. >>> I do have an issue with this though: >>> >>>> 1. Default preference, if locked. (pre-auth) >>> >>> Why does it make a difference if it is locked? A preference value is >>> a preference value. Its locked status does not change the value; >> >> This was the only way in Horde 3 to force the interface to a certain >> language. If we have a different way now to do this that doesn't >> stretch the semantic of a locked preference, even better. > > I just don't see why isLocked() is necessary in > Horde_Registry::preferredLang() is all. I support the idea that > locking the preference prevents language changing, but that should be > handled in the login UI. > >> I disagree, at least if I understand you correctly. The language >> selection in the login screen and the browser's preferred language >> should have precedence over the default preference value, that's what >> we did in H3. >> Though now that I think about it, this would be the only way an admin >> could set a default language for all users without having to lock it >> at the same time. > > Then what's the point of the 'language' preference? > > And maybe I'm reading you wrong, but the login screen language (or > browser detection) is used as the language as long as the 'language' > preference is empty. But once the 'language' preference is filled > with a language, to me that is indication by the admin/user that this > is the canonical language to use, despite the login screen > indication. And we can't hide the language selection on login based > on this value since we don't know what that value is for any given > user. This is probably the more intuitive and logical approach. Thu, 23 Dec 2010 19:45:42 +0000 https://bugs.horde.org/ticket/9437#t61200