With some of the recent talk about the consistency of naming methods in PHP (or lack thereof) Phil Sturgeon has put together some ideas about why this (and unicode) changes aren't happing in the language.

PHP is well known for having an inconsistent API when it comes to PHP functions. Anyone with an anti-PHP point of view will use this as one of their top 3 arguments for why PHP sucks, while most PHP developers will point out that they don't really care. [...] Another big thing that anti-PHP folks laugh about is the lack of scalar objects, so instead of $string->length() you have to do strlen($string). ANOTHER thing that people often joke about is how PHP 6.0 just never happened, because the team were trying to bake in Unicode support but just came across so many issues that it never happened.

He shares an "obvious answer" to the problems and shares a theory as to why it's not happening - that no one is really working on out (outisde of this POC) and some of the handling with the recent property accessors RFC. He finishes off the post with three more points, all related to the results of the voting - little points seem to get voted in easier, the representation of developers in the process and that at least one of the "no" votes had to do with not wanting to maintain the results.

Making changes to this language should not be blocked just because a quiet minority of the core team don't like the idea of being asked to do stuff.

Be sure to check out the comments on the post - there's lots of them, so be sure you have some good time to read.

On Reddit.com there's a recent post with a growing discussion about character encodings in PHP applications (with some various recommendations).

I would rather not have to convert these weird characters to the HTML character entities, if possible. I'd rather be able to use these characters directly on the web page. If this is for some reason a bad idea, let me know. This might be more of a general web design question (i already posted it there), but I figured it is still appropriate to post here as well since PHP is used to pull an entry from the database, and I figured a lot of you here would know the answer to the question.

The general consensus is to use UTF8 in this case, but there's a few reminders for the poster too:

• Don't forget to make the database UTF8 too
• Be sure you're sending the right Content-Type for the UTF8 data
• an link to an article about what "developers must know about unicode/charactersets"

Leonid Mamchenkov has a quick new post to his blog sharing a regular expression that can be used to check that a string contains only English or Latin characters (no Unicode allowed).

Today at work I came across a task which turned out to be much easier and simpler than I originally thought it would. We have have a site with some user registration forms. The site is translated into a number of languages, but due to the regulatory procedures, we have to force users to input their registration details in English only. Using Latin characters, numbers, and punctuation.

Thankfully the PCRE regular expression engine bundled with PHP makes it simple - it uses a standard regular expression without anything special to accommodate for Unicode characters. He notes that adding the "/u" modifier to the expression makes it "totally malfunction" (where strings are treated as UTF-8). If you'd like an example of some of the tricks that go into supporting Unicode in a regex, see this comment in the PHP manual.

On LWN.net there's a new article written up by Jonathan Corbet about the state of PHP6, what it was supposed to be and what it might be in the future.

Rightly or wrongly, many in our community see Perl 6 as the definitive example of vaporware. But what about PHP 6? This release was first discussed by the PHP core developers back in 2005. There have been books on the shelves purporting to cover PHP 6 since at least 2008. But, in March 2010, the PHP 6 release is not out - in fact, it is not even close to out. Recent events suggest that PHP 6 will not be released before 2011 - if, indeed, it is released at all.

He talks about features that were supposed to disappear in PHP6 (with some of them making their way into PHP 5.3) including the Unicode support the language needs more and more. He mentions how the development has stalled out a bit recently but has been spurred back to life when major decisions were made to get away from a PHP 5.4 branch and move back to PHP6.

Be sure to check out the great comments on the post from other PHP developers from all around the web.

If you enjoy this post, please consider subscribing to LWN for more great articles.

With the releases in the PHP 5.x series (5.3 and now a newly branched 5.4), people have been left wondering about PHP 6 and the promised Unicode support it will include. Development on that branch had all but stalled out and things weren't looking too good for the method of introducing full Unicode support to the language. Johannes Schluter has some good news, though - the effort has been restarted and a new approach has been decided on.

Yesterday the stagnation created by the situation has been resolved and it was decided that our trunk in svn will be based on 5.3 and we'll merge features from the old trunk and new features there so that 5.3 will be a true stable branch. The EOL for 5.2 has not yet been defined but I suggest you to really migrate over to 5.3, which usually can be done with very little work, as soon as possible.

Discussion are being made about which type of Unicode support will actually be introduced with a "string class" wrapper gathering some support behind it to provide an alternative to the current string handling.

Johannes Schluter briefly touches on unicode in PHP6 in a new post to his blog and how being able to use it in identifiers can come in quite handy at times.

Consider you have an application tied to an environment with a special terminology, then translating this terms to English might be extremely confusing (especially as programmers often don't really know the correct terminology of that domain) and it's good to call the thing by it's name [...] The purpose of this were some bad news: That's nothing new. The relevant scanner rule hasn't changed since 4.0 - the only change is that PHP 6 doesn't treat it as random set of bytes anymore but knows about Unicode codepoints and interprets is as such.

After digging around a bit in some of the commit history of PHP, Johannes also found that the scanner rule (what parses the identifiers) hasn't changed since around 2000 and, apparently, won't be changing for PHP6 either.

Sean Coates has reposted an article that was originally published in php|architect magazine covering UTF-8 and proper Unicode encoding.

If I had to guess, I would estimate that I've spent somewhere in the range of 40 hours wrangling UTF-8 in the past 3 months, which is not only expensive for my employer, but also disheartening as a developer who's got real work to do. Admittedly, this number is inflated, due to the heavy development cycle we completed with the launch of our new site.

Sean goes on to talk about Unicode issues in general (partially supported in some places, too many points of failure) and some of his other experiences with "the UTF-8 monster" that have given him trouble over time.

In a new post to his blog, Vinu Thomas talks about a set of functions that can make your life easier when handling unicode strings - the mb_* methods of the mbstring extension.

When dealing with multiple languages and internalization in PHP, some of the default functions in PHP end up mangling up the unicode characters in PHP. This is evident when you have a lot of funny looking characters coming up on your web page instead of the actual characters. [...] There is an extensions called mbstring which you can install in PHP which gives you a set of functions which are unicode ( actually multibyte ) ready.

He mentions some of the replacements like mb_send_mail instead o fmail and mb_strlen instead of the usual strlen. Thankfully, there's a simple way to make use of these functions without having to replace a lot of code - a setting in your php.ini (mbstring.func_overload) that tells your application to seamlessly replace things behind the scenes.

Wen Huang has made a quick post to his blog about some of the comments Andrei Zmievski about the future of PHP, specifically on internationalization and UTF-8's place in it.

I attended the SF PHP Meetup last night where Andrei Zmievski (PHP 6 release manager and PHP core team member) gave a talk on PHP 6 and internationalization (i18n). [...] It was evident that Andrei and team have given quite a bit of thought into what i18n means for the PHP world, and as a result, PHP developers everywhere will soon be enjoying a new set of tools to enable faster development of multi-lingual sites.

He also mentions the back-port that several of these features will get into the upcoming PHP 5.3 release (along with the much-hyped namespace support). You can check out Andrei's talk on his website.

On the ThinkPHP blog, Florian Eibeck has posted an overview of some key things to consider when internationalizing your application/website.

The biggest problem is that most developers lack knowledge about Internationalisation, Localisation, Character encodings, Unicode and all those terms connected with multilingualism. The following article should give you a basic understanding and show you how to avoid those funny characters.

He defines a few terms - internationalization, ASCII, unicode and the UTF-8/ISO-8859 character sets. He mentions how to accept the utf-8 string into your application and how to use it in both PHP and store it in a MySQL database.