WordPress and problem with language files (.mo)

While testing the upcoming WordPress 2.3 I noticed that I had a problem with he localization. Defining the language with WPLANG had no effects and all the text were in English as they should have been in Finnish. I installed another instance of WordPress 2.2.3 and the problem was still there. Somewhat confusing because I had a working WordPress instance with the same PHP-version (php-5.2.4_pre200708051230-r2). The only difference was that the other box was 32-bit system and the other 64-bit. Although at that time I didn’t know what to look for.

After some googling I found a Spanish-blog which explained the “bug” and provided a solution. Unfortunately I don’t speak Spanish but the solution was clear with pieces of code to show the way. After I knew what to look for I found some discussions about this topic on WordPress Trac and an entry 2 weeks ago with a patch gettext-64-without-bitwise-ops.diff seems to get the thing fixed.

The problem is in the PHP-gettext which is used for translating strings. The file is located at wp-includes/gettext.php and in that file the problem is created by fixing a bug in PHP 5.0.2 on 64-bit systems. The counterfix is luckily an easy one and you just have to remove some bitwise operators.

The solution with problematic line on red and the fix on green:

wp-includes/gettext.php
line
115	$this->STREAM = $Reader; 
116	$magic = $this->readint(); 
117    	if ($magic == ($MAGIC1 & 0xFFFFFFFF) || $magic == ($MAGIC3 & 0xFFFFFFFF)) { // to make sure it works for 64-bit platforms
117	if ($magic == $MAGIC1 || $magic == $MAGIC3) { // to make sure it works for 64-bit platforms 
118		$this->BYTEORDER = 0; 
119	} elseif ($magic == ($MAGIC2 & 0xFFFFFFFF)) { 
120		$this->BYTEORDER = 1; 

The search engines <3

Update, 2008-02-05:
With WordPress 2.3.3 this bug is finally closed with some other minor bug fixes and security fix for xmlrpc.php.