Yeah, look like was wrong. Probably because it is empty by default.

This is probably the more intuitive and logical approach.

In Horde 3 the check for $nls['defaults'] occurs before the check for 
HTTP_ACCEPT_LANGUAGE.  At least in NLS::select().

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.
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.

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

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.

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.

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.

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.

I re-cleared FF's cache and *cookies*, and now it is working.
Thanks.

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.
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 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.

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

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.

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')));

still not working. I deleted prefs and cache before trying.

I'll try to look at Horde_Registry::preferredLang()

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:
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.

That's not quite correct.

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)

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)

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.

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

Look at Horde_Registry::preferredLang() - it should reach the second 
if clause if it is working properly.

I'm still having this issue.
Need a trace ? Where can I look ?

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.

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

Michael just fixed a bunch of issues with language selection in the 
login screen. Does this fix your problem?

$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.