I've tried all sort of:
NLS::getCharset(true)
NLS::getCharset('ISO-8859-1')
NLS::getCharset('UTF-8')

but the address book was not displayed.

Best Regards,
Mike Rhyner

Does it work if you change the 'charset' parameter in config/sources.php to:
'charset' => NLS::getCharset(true)

php status page

horde test pages

We are a mid-sized ISP in Central Switzerland.

After adding an UTF-8 locale,  e.g. en_US.UTF-8 to the system locales 
so customers would be able to display e-mail messages in UTF-8 
encoding, and private addressbooks of customers having entries 
containing special characters like Umalut, etc, no data will be 
displayed. We have stored data on a mysql 5 server using the 
"iso-8859-1" character set and indicated that fact within 
config/conf.php by telling:
$conf['sql']['charset'] = 'iso-8859-1';

After turning on display_errors within php.ini, the following error 
messages apper:
"Warning: array_values() [function.array-values]: The argument should 
be an array in /var/www/horde/turba/lib/Driver/prefs.php on line 32

Warning: Invalid argument supplied for foreach() in 
/var/www/horde/turba/lib/Driver.php on line 541"

First, we tried to change the setting within turba/config/sources.php:
'charset' => NLS::getCharset()
to
'charset' => 'ISO-8859-1'
But that has changed nothing. After investigating a bit, we've seen 
within the file "turba/lib/Driver/prefs.php, "de-serialization will be 
done after converting the character set from ISO-8859-1 to UTF-8. That 
leads to a failure to unserialize the whole addressbook because the 
byte-length indicated before does not any more correspond to the 
effective byte-length of the respective string if the user had entered 
special characters (ASCII Code > 127).

All other functions are working as expected even using an UTF-8 
enabled system locale, e.g. all other settings stored within the prefs 
backend like Identity, E-Mail settings, etc. So I assume there must be 
something wrong/different with turba prefs storage functions compared 
to the other prefs functions.

For example, within lib/horde/Identity.php starting at line 87, it let 
me assume that at least some tries are being done with and without 
charset conversion so there is a chance to handle both situations 
(conversion needed and not needed before unserialization):
         if (!($this->_identities = 
@unserialize($this->_prefs->getValue('identities', false)))) {
             /* Convert identities from the old format. */
             $this->_identities = 
@unserialize($this->_prefs->getValue('identities'));
         } elseif (is_array($this->_identities)) {
             $this->_identities = 
$this->_prefs->convertFromDriver($this->_identities, NLS::getCharset());
         }

As a workaround, we have to either leave all including the system 
locale to not using UTF-8 and further live with e-mail messages using 
non-iso character sets not being displayed directly (until after 
clicking the link opening a new window in the respective encoding).

Another possibility could be converting all data within the database 
to UTF-8 (and swithing to utf-8 within configuration of course), but 
that leads to even more problems with serialized data within e.g. the 
whole preference settings (no data is displayed e.g. for Identity 
settings, etc.) because data would then be stored as UTF-8 strings, 
but the byte length indicated will be wrong).

Attached you will find horde and turba configuration files.

Thank you in advance for some help or even better a fixed version so 
we are able to use ISO-8859-1 within the databaes, but display content 
as UTF-8 as it seems to be possible.

Regards,
Michael Rhyner
Medianet AG