Problem with forum in spanish

Hi, thanks for your answer. I wonder if there is another way... It seems that converting the charset of an already installed Wordpress is not a simple process...

Just checking on this. Was going to convert to UTF8 as I'm in the process of reinstalling the forum server. Doing the following is all that is required on an English only database? Or is there something else I've missed? This is a postgresql db, btw, so the database types I've created as UTF8 in preparation. PHP has also been compiled with mb_strings.

In include/dblayer/common_db.php after this line:

$db = new DBLayer($db_host, $db_username, $db_password, $db_name, $db_prefix, $p_connect);

add this line:

$db->query("SET NAMES 'UTF8'");

In LANG/common.php, altering the lang_encoding line to:

lang_encoding' => 'utf-8'

Have I found everything I need to do? (Other than changing any specific iso-8859-1 entries in other files to utf8).

Cheers,

Matt

Cheers Smartys. Did the conversion, (only one db required conversion due to it having characters the UTF8 format wasn't happy with), and it all appears to be working fine now.

Thought I'd just pop some further info up on this too, incase it's ever useful in the future for someone else.

Firstly, don't make the stupid mistake I wasted two hours upon. Mysql, if I remember correctly, just dumps a text version of the database when you do a dump. Pgsql, however, allows you to select several formats for the dump. Guess who didn't do a plaintext flatfile when he should have. The command for pgsql, to do a db dump which will allow it to be converted is:

pg_dump [database_name] > [output_file]

If one uses the -Fc option to pg_dump, it won't be suitable for conversion. To reload the file after conversion, the command is:

psql -d  [database_name] < [converted_file]

Running the command:

iconv -f ISO-8859-1 -t UTF-8  [output_file] > [converted_file]

will change the formatting of the characters, (in the above example from is0-8859-1), to utf8.

Also, the SET NAMES addition to the common_db.php file isn't required for Pgsql. It will already return the client_encoding type depending upon the database type, so it's appears to be a moot requirement with Pgsql. The command:

$db->query("SET NAMES 'UTF8'");

is an alias for, (to give it the true Pgsql syntax):

$db->query("SET 'client_encoding' TO 'UTF8'");

Finally, to create a utf8 db in Pgsql, (the default is SQL_ASCII), the command is:

createdb -E UTF8 -O [database_owner] [database_name]

Hope this is of some help.

I would set it

Just been running through the Mysql bit as well. Pgsql is far easier to convert. Few notes for future reference, though.

Firstly, doing a dump of the db to flatfile, run the iconv command above on the dump, and then secondly it needs this running on the dump file:

sed -e 's/latin1/utf8/g' < [converted_file] > [converted_utf8]

That will change all the, (in this example), latin1_swedish_ci entries to utf8_general_ci entries in the dbfile.

To create a utf8 db with Mysql, the command is:

mysql -u [db_username] -p --execute="CREATE DATABASE [db_name] CHARACTER SET utf8 COLLATE utf8_general_ci;"

It can be verified that the collation and character sets are correct by using mysql to connect to the database then issuing the commands:

show variables like "character_set_database";
show variables like "collation_database";

Plus, if all the databases are going to be in utf8 format, the 'SET NAMES' addition to the common_db.php file can be mooted by running mysqld with the following options to start the server:

/[path_to]/mysqld\
        --character-set-server=utf8\
        --collation-server=utf8_general_ci\
        --skip-character-set-client-handshake

That should make Mysql run using utf8 as default, and will make it ignore the client encoding requested/sent by the client. I have one programme using Mysql here which I'm going to adapt to use utf8, so I'll let you know when I've tested it if anything fails spectacularly.