El 09/03/10 10:20, Raymond Wan wrote:
Javier Bezos wrote:
CREATE TABLE `wl_archive` ( `ar_namespace` int(11) NOT NULL default '0', `ar_title` varchar(255) character set latin1 collate latin1_bin NOT NULL default '', [...] ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
and now they are like
SET @saved_cs_client = @@character_set_client; SET character_set_client = utf8; CREATE TABLE `wl_archive` ( `ar_namespace` int(11) NOT NULL default '0', `ar_title` varchar(255) character set latin1 collate latin1_bin NOT NULL default '', [...] ) ENGINE=InnoDB DEFAULT CHARSET=utf8; SET character_set_client = @saved_cs_client;
This is the exact problem that I had. I had a database with a mix of English and Japanese and could see everything fine. I then checked both the database and the system and found out they were both set to "latin1". If so, I don't know why it had worked for so long...
So, what I did was change the database and the MySQL system to utf8. But then the database also has to be converted and this failed miserably for me. I followed these steps:
http://en.gentoo-wiki.com/wiki/Convert_latin1_to_UTF-8_in_MySQL
which did not work (more specifically, the "Convert dump" step).
That's wrong. Even when the database shows charset=latin1, mediawiki stores utf8 inside. So you shouldn't have tried to convert the content, that would have broken it.
In the end, I re-typed the Japanese (which wasn't a lot). So maybe you might have better luck or someone else can help you. Or maybe you can make some sense of the above link and succeed where I failed. :-)
Good luck...
Ray
Javier, you need to what's the data representation and set to one (either latin1 or utf8), I think you had some tables latin1 and others utf8 now. With $wgDBmysql5 set accordingly.
Without knowing the exact way your db is broken, it'd be hard to fix it. What search are you using? The internal one? Maybe you can share a one-revision sql dump?
PS: Update to 1.15.2, you are vulnerable to CSS image inclusion.