[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         | Jan Schneider <jan 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
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2010-12-23 14:45) 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().

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.