Feature request: disabling new HTTP_ACCEPT_LANGUAGE detection in 0.2-beta?

[fili]

The new 0.2-beta release introduces the ability to auto-detect client language based on the presence of HTTP_ACCEPT_LANGUAGE.
See ticket (#1484434)

This might be a great feature for some, but this could also be undesirable for others.
Because:

• A lot of people are using a browser language version that does not match the language they are speaking
• Most browser do not allow this setting to be altered with ease

In our scenario (we offer services in dutch) the number of non-dutch speaking users is trivial.
However chances are some of these dutch users will now be faced with an english login-screen.
Please make it possible to disable this new feature and globally set a default language.

Thanks in advance and kudos for this great project!

[rosali]

#1485401 (Disabling new HTTP_ACCEPT_LANGUAGE detection in 0.2-beta by config) ? RoundCube Webmail ? Trac

[JohnDoh]

I belive this is already configurable...

Code Select Expand


// the default locale setting (leave empty for auto-detection)
// RFC1766 formatted language name like en_US, de_DE, de_CH, fr_FR, pt_BR
$rcmail_config['language'] = null;


auto detection is only used if no language is specified.

[fili]

Agreed, you would think so. Alas it doesn't seem to work that way.
I have the following in my main.inc.php:

$rcmail_config['language'] = 'nl_NL';

And it still try's to auto-detect the language.
Maybe its broken?

[JohnDoh]

I see, I will try it later. what is the language in your user settings (personal settings) it this is set to auto then it will override what is in your config file. This would happen if you had $rcmail_config['language'] = null; when you first logged in and then changed it later to nl_NL.

[rosali]

Personal settings should not affect login page where user is logged out, or?

I do not know if it is the appropriate place, but I fixed it in rcube_user.php ...

Code Select Expand


  /**
   * Get the preferences saved for this user
   *
   * @return array Hash array with prefs
   */
  function get_prefs()
  {
    // find me: fix default language
    if(empty($this->language)){
      $this->language = $GLOBALS['CONFIG']['language'];
    }
    $prefs = array('language' => $this->language);
   
    if ($this->ID && $this->data['preferences'])
      $prefs += (array)unserialize($this->data['preferences']);
   
    return $prefs;
  }


[fili]

what is the language in your user settings (personal settings) it this is set to auto then it will override what is in your config file.

The auto-detection takes place on the login-screen before logging in.
Therefor user settings do not influence the language detection at that point.

/**
* Get the preferences saved for this user
*
* @return array Hash array with prefs
*/
function get_prefs()
{

This bug (?) should, for the same reason, not be fixed by patching a function designed to retrieve user-preferences.

With the (unreliable) HTTP_ACCEPT_LANGUAGE variable one can make an educated guess about the user's language.
For some roundcube installations this would make perfect sense, since there currently is no better method of detecting this.
In our scenario however, we already know in which language we wish the login-screen to appear.

[JohnDoh]

ahhhh right, now i understand. i didnt realise the problem was on the login screen. rosali's patch should work i think and also this (its just a slightly shorter way of doing it since the global config is already read in else where)

Code Select Expand


--- roundcube_svn/program/include/rcube_user.php        2008-09-21 12:43:36.000000000 +0100
+++ roundcube_dev/program/include/rcube_user.php        2008-09-23 18:54:52.000000000 +0100
@@ -78,8 +78,9 @@
    */
   function get_prefs()
   {
-    $prefs = array('language' => $this->language);
-
+    if(!empty($this->language))
+      $prefs = array('language' => $this->language);
+
     if ($this->ID && $this->data['preferences'])
       $prefs += (array)unserialize($this->data['preferences']);



fili: rcubd_user is the right place to make the change because the problem is caused by merging a blank user config with the global config (causing the language information in the global to be lost)

If either of you could please confirm this works i will attach the patch to the ticket in trac.

Thanks

[rosali]

Works also ... !!! Yes, you are right. No need to use a GLOBAL here.

[JohnDoh]

patch applied to trunk in r1888

[fili]

Thanks the patched worked here as well!