The DevX website has recently posted this tutorial - a look at simple internationalization for your website.

If you develop Web applications that have an international target audience, then you have to take internationalization into account'"a process that includes avoiding date/time or currency confusions and delivering all text pertinent to the user interface in the user's preferred language. Applications that can grow international traffic and improve revenue must respect their clients' needs.

They use the I18N PEAR package to handle most of the hard work and include the howto on grabbing the package, the structure and how to use it to get a country name from a code, work with the translation of numbers, currency and changing up date/time strings.

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.

The CakePHP podcast, "The Show" has posted their latest episode - The Low Down On Internationalization (i18n):

Larry Masters joins us once again to discuss internationalization and localization features in the upcoming CakePHP 1.2 release.

You can download this edition directly from their servers (via the mp3 link) or you can point your favorite feed reader at their podcast feed and get each show as it comes out.

Gerd Schauffelberger introduces a new package today as a part of his work with the pat-tools group - the patI18n package for internationalization.

In lack of a better idea, I founded a new PAT Package: patI18n. So far this package is just a draft and only exists in the SVN repository. As you might guess, patI18n is an abstraction layer for translating issues. Therefore it provides nearly the same interface as the famous GNU Gettext. Still, the actual translation is done by a chain of modules - this way everything is possible and the design stays open to new ideas.

He talks briefly about how it came to be and how it varies from some of the more traditional language translation tools. You can check out the example on his development environment or just use the snv details provided to grab the latest copy.

PHP-GTKers working in English-related applications, don't have a problem with debugging messages output to a console when debugging, but applications on a more international front have issues with their output. But help has been found in this new post on the Riff Blog - a method for correctly encoding PHP-GTK applications.

PHP scripts are typically stored under UTF-8 encoding to limit i18n headaches, while the console in which their output will be displayed is normally configured to some regional encoding, like IBM850 in Windows/XP French.

So we need a workaround...

He splits the process out into a few steps, each with its own explanation and code:

• Builtin tools
• Buffering
• Flushing
• PHP-GTK is not PHP for the Web
• Auto-flushing

All wrapped up with a final solution - using the iconv functionality in combination with some output buffering to correctly display the message.