function uc ( $str, $first = false ) // in file LanguageUtf8.php, mediawiki-1.7.1.tar.gz
…
return preg_replace( "/$x([a-z]|[\\xc0-\\xff][\\x80-\\xbf]*)/e", "strtr( \"\$1\" , \$wikiUpperChars )", $str );

See their lookup table, they have also “a-z=>A-Z” arrays there:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Utf8Case.php

This has to be slow.

Why it should not be enough just:

if (!$first) return strtr ($str, $wikiUpperChars); // ?

I wonder why they didn`t implement native utf8 support in php5. its so 90ies…

It’s not a problem you can solve easily plus it’s a lot of work. The tipping point was IBM open sourcing ICU - http://en.wikipedia.org/wiki/International_Components_for_Unicode - that saves the work

It’s almost too much to take in. So again, I praise the day when full i18n support is implemented into PHP and I can find a gutsy host that will upgrade quickly.

I think that’s a very forgiveable perspective but at the same time, it’s worth battling on. PHP6 is going to make the problem easier to manage but I don’t think it’s going to make the problem magically vanish. What I also worry is whether it may be a mistake to make all strings Unicode with a flick of a php.ini file - there are issues related to security such phishing-type attacks (unicode characters which look almost like normal ASCII characters) - have yet to clarify exactly how PHP6 is going to look like though, so that may be FUD.

The real issue is character encoding is a leaky abstraction - it’s very hard to hide it behind APIs.

If there are two key points to getting it in PHP I’d say it’s to consider PHP’s problem - http://www.phpwact.org/php/i18n/charsets#php_s_problem_with_character_encoding then look closely at the table here: http://en.wikipedia.org/wiki/UTF-8#Description - examine the 0’s and 1’s it’s describing. Eventually it will fall into place.