[Tickets #9437] Re: Language selection at login fails

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/9437
------------------------------------------------------------------------------
  Ticket             | 9437
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Language selection at login fails
  Queue              | Horde Base
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2010-12-23 14:12) wrote:

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