The SitePoint PHP blog has a new tutorial posted by editor Bruno Skvorc showing you how to set up an online multi-language magazine with the help of the Sulu CMS. This article is a follow up to their previous "Getting Started" tutorial helping you get Sulu up and running.

We previously demonstrated the proper way to get started with Sulu CMS by setting up a Hello World installation on a Vagrant machine. Simple stuff, but can be tricky.

[...] This time we’ll look into basic Sulu terminology, explain how content is formed, created, stored, and cached, and look into building a simple online magazine with different locales (languages).

The tutorial then covers pages and page templates including what the Twig markup looks like, how to work with them in the UI and the end result of their sample "Hello world" page. There's a brief section about caching before he moves into the main part of the tutorial: the creation of the magazine. He covers the use of Jackalope, ElasticSearch and the ArticleBundle and how to get them up, running and playing nicely together. The article wraps up with a look at locales and how they work in the Sulu setup.

The SitePoint PHP blog has a post from editor Bruno Skvorc showing you how to integrate gettext with Twig to make it easier to internationalize your application with multiple languages and strings.

There are many approaches for adding new languages to your application’s UI. Though some userland solutions like symfony/translation are arguably simpler to use, they’re slower than the good old native gettext by an order of several magnitudes.

In this tutorial, we’ll modify an English-only application to use gettext. Through this, we’ll demonstrate that getting internationalization up and running in an already existing app is not only possible, but relatively easy.

He starts with some of the bootstrapping you'll need to do to get the "nofw" project up, Twig installed and them hooked together. He briefly introduces gettext and how it's used in PHP (with the _() handling) and provides an example defining a locale and the language files to match. He shows how to generate the .pot files, add a new language and the code needed to hook in the Twig_Extensions_Extension_I18n extension. The post ends with some "bonus scripts" to help make things a bit simpler: bash scripts to hide some of the complexity of the process.

The Laravel News site has a tutorial they've posted showing you how to help internationalize your application by adding multilingual support to Eloquent in your database schemas.

Did you know that several countries throughout the world have more than one official language? For example, my home country Belgium has three; French, Dutch, and German. Most Belgians also speak English. Laravel’s Eloquent ORM is a very powerful part of Laravel. Unfortunately, it doesn’t provide support for multilingual models out of the box. Adding that functionality yourself isn’t that difficult.

They start with a basic migration with no multilingual support included, a simple "articles" table. They show how support could be included by adding columns for languages but suggests that using a "translated" table for the other versions is a better option. With this schema in place, they then show how to use the laravel-translatable package and Translatable trait to handle the pull and push of the translated data from the database automatically. It can even be set up to pull which version it should display directly from the application's locale setting.

Simon Holywell as written up a tutorial for his site showing you how to use setlocale to do PHP date localization.

Localising sites can be a chore, but PHP has the venerable setlocale() to use system locales. These are like templates or profiles that describe how various types of data should be displayed. Should a price have a comma or point to indicate the decimals? When printing a date should PHP output Monday or Montag?

All of these considerations are locale specific and they map to a geographical area. Various cultures have their own standards for displaying this kind of information not to mention different languages to accommodate.

He shows how to find the locales your system supports and how to install them if the one(s) you need are missing. With it correctly installed, the system knows how to use it but PHP needs a little extra help. With a call to the setlocale method and the use of a special date string modifier (in this case "%B" for the month name) PHP knows to use the locale-aware version of the data...but only with strftime not the normal PHP date handling.

PHPMaster.com has posted its third part of its "Localizing PHP Applications 'The Right Way'" series. In this third part you'll learn more about locales and message domain switching.

In Part 2 you gained more insight into using the gettext library by learning the most important functions of the extension. In this part you’ll learn how to best use a fallback locale, switch between locales, and override the currently selected message domain.

They show you how to set up the directory structure to handle a fallback locale, a choice to use when the system can't determine which to use. By using a default, you also avoid having the system translate from the default language to...the default language (like "English" to "English"). Included are also the code bits you'll need to switch between locales (just using a different domain) and using the dgettext function to specify a different domain than the selected one.

Evert Pot found out an interesting thing about the basename function in PHP - it's more than just a handy shortcut for paths, it's also locale aware.

It turns out basename does a bit more than just splicing the string at the last slash, because it's locale aware. In my case I was dealing with a multi-byte UTF-8 string. It took me quite some time figuring out what was going on, because I was testing from the console which had the en_US.UTF-8 locale, and the bug was appearing on Apache, which defaults to the C locale.

He includes an example snippet of code showing how it can work with both the default (well, for Apache anyway) of the "C" locale versus the "UTF-8" locale and return different results for the same urldecoded information.

Padraic Brady has posted about an issue he noticed when working with regular expressions and the "word" character type to find something that's alpha-numeric (including an underscore):

You can find the "word" generic character type used in a lot of PHP code including the Zend Framework. The problem is that the assumption above is incorrect. Now, most of the time these act identically because PHP is compiled using its own packaged PCRE library. However, I've seen more than once systems where this is not the case. Usually in some non-English capacity where additional locale support was considered necessary or standard practice.

The problem comes when PHP is compiled against a custom PCRE library, making it more locale-aware. He gives instructions on how to get this to a testable state on your environment (using an updated PREC library) and get it working for characters in French, like the accented "a" or "e".

On WebReference.com there's a recent article looking at the PEAR internationalization (i18n) packages and how they can be used to internationalize your application.

For many of us, the realization of the extent of countries' interdependence was driven home by the recent global economic meltdown. So what does all this have to do with us Web developers? It's a resounding wake up call that we have to think of other nationalities when we develop our websites and applications. In most cases, developing a web app in English alienates much of the world's population and greatly reduces potential profits! With that in mind, this article is the kickoff for a series that discusses the ramifications of globalization on our websites and applications.

The look at some of the local identifiers (like LC_ALL, LC_TIME, LC_ADDRESS and LANG), how to access the values for them on the different OSes and how to use the I18N_Country and I18N_Language packages from the PEAR I18N package to handle some simple multi-language support.

Paul Jones has released two new concurrent versions of the Solar framework today:

Yesterday, I released Solar 0.27.0, then quick-fixed two minor bugs and released 0.27.1 an hour later. It feels so good to be back doing releases on a monthly basis.

Some of the updates/changes in these new releases include:

• The use of spl_autolaod to load classes
• Locale functions have a new home
• a super-fast JSON encoder/decoder
• a modification to the SQL adapter for PDO
• A new bit of functionality in Solar_Url that can find the ".ext" filename extension in a URL automagically

Paul Jones has released two new concurrent versions of the Solar framework today:

Yesterday, I released Solar 0.27.0, then quick-fixed two minor bugs and released 0.27.1 an hour later. It feels so good to be back doing releases on a monthly basis.

Some of the updates/changes in these new releases include:

• The use of spl_autolaod to load classes
• Locale functions have a new home
• a super-fast JSON encoder/decoder
• a modification to the SQL adapter for PDO
• A new bit of functionality in Solar_Url that can find the ".ext" filename extension in a URL automagically