[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 06:06) 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.

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