My b2evolution Version: 2.x/3.x

In this post, I will use UTF-8.

/**
 * The internal charset. It's used to convert user INPUT/OUTPUT and database data into for
 * internal use.
 *
 * Setting it to an empty string means "follow the user's charset", which gets
 * taken off his locale (INPUT/OUTPUT charset; {@link $io_charset}).
 *
 * If you don't know, don't change this setting.
 *
 * This should be supported by {@link mb_list_encodings()}.
 */
$evo_charset = '';

Should be supported by mb_list_encodings();
According to: http://php.net/mb_list_encodings
The UTF-8 support of mb_list_encodings is "UTF-8".

So now, let's set it to:

$evo_charset = 'UTF-8';

Next:

/**
 * Set this to a specific charset, to force this as {@link $io_charset I/O charset},
 * if the browser accepts it.
 *
 * Setting this to "utf-8" allows you to deliver all pages in this encoding.
 *
 * NOTE: make sure, that your PHP/MySQL setup supports this. You most probably need
 *       the mbstring PHP extension and MySQL 4.1 for this to work.
 *
 * @global string
 */
$force_io_charset_if_accepted = '';

The same as above, this will become:

$force_io_charset_if_accepted = 'UTF-8';

If my understanding is correct, it should be "UTF-8" not "utf-8" - also as per the Locales registry and RFC lists, it's written as "UTF-8". However, some setups recognize "utf-8" just to get rid of unnecessary support-tickets from their customers.

Anyway, now we have this:

/**
 * Request a specific charset for the client connection.
 *
 * This will issue a MySQL SET NAMES command. This must be a MySQL charset. Example: 'latin1' or 'utf8'
 *
 * If left empty, the default charset will be used. The default here is
 * the default set your MySQL Server.
 *
 * This should match the charset you are using internally in b2evolution.
 * This allows b2evo to work internally in a different charset from the database charset.
 * Example: b2evo will use latin1 whereas the database uses utf8.
 *
 * TODO: This gets overridden anyway with "SET NAMES $evo_charset" in init_charsets() and gets only used until that!
 *       So, does it make sense to configure it here? Or shouldn't it get overridden, if set explicitly here?
 */
$db_config['connection_charset'] = '';

mySQL recognize "utf8" not "UTF-8" as per this manual: http://dev.mysql.com/doc/refman/5.0/en/charset.html && http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html

So we should have then the following setting:

$db_config['connection_charset'] = 'utf8';

However, there's a "TODO" note that states:

 * TODO: This gets overridden anyway with "SET NAMES $evo_charset" in init_charsets() and gets only used until that!
 *       So, does it make sense to configure it here? Or shouldn't it get overridden, if set explicitly here?

If earlier our $evo_charset is "UTF-8" and it is used to "SET NAMES $evo_charset" then it will be wrong since mySQL only recognizes "utf8".

Now, if we leave #evo_charset empty, then it will use the user's locale as stated above:

 * Setting it to an empty string means "follow the user's charset", which gets
 * taken off his locale (INPUT/OUTPUT charset; {@link $io_charset}).

If my understanding of that is correct, it will pull-out the charset from a locale, example English (US) [for this example, English (US) has been setup as UTF-8].

Then same process again, $evo_charset will become "UTF-8" then is used as "SET NAMES $evo_charset". Which mySQL will not recognize.

Now, I'm sure I'm wrong somewhere here, so any clarification about these settings?

PS
* It's about UTF-8 so a b2evolution blog can use scripts found in Unicode ranges, like fil-Tagb = http://en.wikipedia.org/wiki/Tagbanwa_script or fil-Tglg [ http://en.wikipedia.org/wiki/Baybayin ]
- not to mention, a multi-lingual blog setup

Thanks again.