ElkArte Community Modern, Free, Powerful
Community building forum software

While digging through Util.class.php I actually wondered why that file is full of workarounds for things which already are in the PHP multibyte extension.

If mb_ is available, quite the whole file can be dropped. As I highly doubt that there are any major PHP hosters left where installing mb is neither possible nor allowed, I'd advise to just cut those functions down. Why reinvent the wheel?

In Who.german.formal.php, I make use of the mb_ functions to keep things straight. I see no sense in having redundant functions hanging around, wasting resources and maintenance time.

I think we can look at this again in 1.1 as I think all the mb_xxx stuff was part of PHP core starting at 5.3 so we are ensured its available .... 1.0 we still support 5.2 (made sense when we started!) although its strongly recommended to be 5.3 since that is the direction we are on with 1.1

Util also has some character encoding logic that I'm not sure we can completely drop in favor a mb_ function but then again have not looked at that file in some time.  The old upper / lower case thing and that translation file should be able to go.

Character encoding is respected by mb_.

On my FreeBSD server with PHP 5.5, multibyte is still an external extension required to be built separately. Not sure how it is on other systems. emanuele kindly (and weirdly) noticed that my language file could fail (and spit out PHP Errors, I guess) when the extension isn't available. Not sure if I should add a workaround.

Strange that its external in 5.5 but hey ho thats the way it goes