Site settings -> Internationalization -> Determine language from : sitellite_preferences doesn't work

Error message:

Fatal error: Call to undefined function session_pref() in /home/sites/semias/public_html/opensource.sitellite.nl/saf/lib/I18n/I18n.php on line 678

The problem is that I18n constructor calls negotiate member function, which calls session_pref function. But in the main index file, I18n intl global object is build before session global object. session_pref is defined in Session.Acl, which is included by Session.Session. John, can you check that? I don't want to mess up the main index file...

It's actually not as simple as changing the order of things loading in the index file. The more I've tried that, new issues come up in the loading order and I don't want to preload everything for one setting since that would slow things like the page cache down.

The i18n package is used by the cache, but I don't want to require the session packages as well as a database connection when the cache is just reading from disk and in order to use this method there needs to be a database connection to retrieve the preferences from the sitellite_prefs table.

The best way to rewrite this would probably be to check if the $_POST['username'] value exists and set a cookie with the language preference once, so the database query only runs when they first log in and the value is available to each subsequent request. Something like this:

if (isset ($_POST['username'])) {
    $lang = db_shift ('select value from sitellite_prefs where username = ? and pref = "lang"', $_POST['username']);
    if (isset ($this->languages[$lang])) {
        global $cookie;
        $cookie->set ('sitellite_lang_pref', $lang, '', '/');
        return $lang;
    }
} elseif (isset ($cookie->sitellite_lang_pref)) {
    return $cookie->sitellite_lang_pref;
}

But this doesn't work because there's no database connection yet. I'm leaning towards just removing that option from the site settings, since there are already 3 other methods for determining the language anyway. What do you guys think?

Yes, I think you could remove this option. It doesn't make sense have this as a user preference. Preferences are related to logged users, but what do you do if there are no users logged? And there is already the 'default language' setting in Multilingual-app to manually specify the language to use.