Last modified: 2013-02-25 17:15:32 UTC
Track issues with MySQL 5.0, charset/collation work etc on this bug.
I'm using mediawiki-1.5.0 with MySQL 4.1.14, which is set to use UTF8 as the default charset. However, because most other old web apps here use Latin1, the default connection charset is set to Latin1 (in my.cnf: init-connect = 'set names latin1'). I.e. the MySQL server keeps everything in UTF8, but talks Latin1 by default to the clients. Because mediawiki is fully capable of using UTF8, it can/should talk UTF8 directly with the database, so I changed includes/Database.php to tell MySQL that mediawiki wants to talk UTF8: --- mediawiki-1.5.0/includes/Database.php 2005-08-28 23:59:17.000000000 +0200 +++ wiki/includes/Database.php 2005-10-23 19:06:24.000000000 +0200 @@ -223,6 +223,7 @@ # may cause some operations to fail possibly. @/**/$this->mConn = mysql_connect( $server, $user, $password ); } + $this->query('SET NAMES utf8'); } if ( $dbName != '' ) { This works fine, but should probably have an additional check like: if mysql_version >= 4.1 then send "set names utf8". mediawiki-1.5.0 was also able to display everything correctly while talking Latin1 with our database, but I suppose in that case mediawiki did the translation from latin1 to utf8 (because pages were displayed in utf8). I suppose, letting the database to the translation scales better than changing encodings in PHP. Also there was a minor glitch with pages that have german umlauts in their name. The page links were displayed in red (not existing), even if they existed. And if you click the link, the edit page came up and the textbox was filled with the content of the existing page.
Please do not place specific comments on this bug, this is a tracking bug. File new bugs, and list this bug as dependent on it.
Adding 'tracking' keyword.
No open dependencies left and 5.0 was released in 2005 => closing as FIXED.