The Toptal.com site has a tutorial posted from Igor Gomes dos Santos about building a multilingual site with a combination of gettext and PHP.

Whether you are building a website or a full-fledged web application, making it accessible to a wider audience often requires it to be available in different languages and locales.

Fundamental differences between most human languages make this anything but easy. The differences in grammar rules, language nuances, date formats, and more combine to make localization a unique and formidable challenge. [...] The way your code is organized, and how your components and interface are designed, plays an important role in determining how easily you can localize your application.

The tutorial starts off talking about some of the difficulties that come along with internationalization of an application and how localization comes into play. He then starts talking about gettext and links to several PHP libraries that can help you integrate support for it into a current (or new) application. He walks you through the setup of gettext, how the PO/MO files are structured and other things to like about like domain separation, locale codes and the directory structure of your PO/MO files. He then gets into a practical example, showing a sample PO file's contents, two schools of thought on the identifiers in the file and a simple template that uses the "gettext" to get a translation. He also includes code to set up the locale correctly and create the language files for it to use.

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.

On the SitePoint PHP blog today Aurelio De Rosa makes some recommendations about handing gettext translations on shared hosting. The problem with shared hosting is the need to reset the web server (Apache) to get it to read the updated translation files. His workarounds uses an external script that can dynamically pull in the latest translations without the restart.`

For serious translations we can use Gettext. This approach enables us to have different files for every targeted language which helps in maintaining separation between the business logic, the presentation layer, and the translations (which we can see as an add-on of the presentation layer). With Gettext, we can parallelize the process because while we’re working on some features of the website, translators can still work on translations using software like gettext functionality to set the current language and extract a "HELLO_WORLD" string. He then moves on to the use of the Audero Shared Gettext library. This library creates a "mirror" of the translation file requested and forces those updates into the current domain. Code examples of its use are included showing a basic pull and merge process.

On Lingohub.com there's a recent tutorial posted about using gettext for the internationalization of your application. The gettext functionality lets you define POT files (portable object templates) that contain the strings for the given language.

GNU gettext is a package that offers to programmers, translators and even users a well integrated set of tools that provide a framework within which other free packages may produce multi-lingual messages. [...] In this tutorial we want to document how PHP internationalization with gettext works. It covers setup, use and best practice.

They go through the installation of both the gettext software and how to get support for it built into PHP. There's a detailed guide to creating the POT files and the formatting you can use to define things like simple messages, plurals and multiple response messages. An example file is included to illustrate. They also talk about the directory structure to use and how to get it working in PHP (sample code).

In this new post to the Umpirsky.com development blog, they show you how to use poedit to extract translations from Twig templates.

By default, Poedit does not have the ability to parse Twig templates. In Twig documenation there is a simple example which shows how to extract translations. This can work with few modifications, but I wanted to make reusable tool which will allow you to parse Twig templates just like you do with plain PHP templates.

The result is the Twig-Gettext-Extractor that's set up inside Poedit as a parser command for "*.twig" files. This automatically extracts the information so that the editor can read the data from the template.

PHPMaster.com has posted the fifth part of their "Localizing PHP Applications 'The Right Way'" series, this time with a focus on extracting data from the .pot template files to define in your PHP. (This is the final part of the series.)

In Part 4 you learned how to use gettext for one of the most complex aspects of localization a developer can face, plural forms. In this, the final part of the five-part series, I’ll teach you how you to automate part of the localization process by extracting msgids and generating a PO template file (.pot) from your application’s PHP code.

They show how to use the xgettext command-line tool to pull out strings from your source and automatically make them into a domain template. They help you set up three sample PHP files and run the xgettext command on them to pull out messages defined in the text of the files to set up keys in the template. Screenshots are included showing how to use Poedit to use these templates for your new translations.

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.

PHPMaster.com has posted the second part of their series about localizing PHP applications "the right way" (hint: it uses gettext).

Welcome back to this series of articles which teach you how to localize your PHP applications using gettext and its PHP extension. In Part 1 you took your first steps towards towards this by installing gettext and Poedit, creating a translation file, and writing a Hello World script. In this part you’ll lean about each of the function used in the script, and dive more into the gettext library and its usage.

The explain some of the naming conventions gettext uses for things (like "domains" and "codeset") as well as the shorthand "_()" you can use to retrieve translated values. There's also a look at supporting multiple locales via multiple directories of .po and .mo files.

PHPMaster.com has a new tutorial sharing what they call the right way for localizing PHP applications with the help of PHP's gettext functionality.

Localizing software applications in general used to be a cumbersome and error-prone task resulting in a lot of messy code. Some developers even use different versions of code for the same application but for different locales, which makes managing the codebase practically impossible. Enter gettext, the wonderful open-source tool that will make your life easier by allowing you to concentrate on your code. Localization becomes a matter of writing separate translation files for the target language, which can easily be done by a translator using Poedit.

They help you get your environment set up - PHP and a href="http://poedit.net/">Poedit, a gettext catalog editor - for both linux- and Windows-based OSes. They walk you through the creation of a simple project and a few basic "hello world" tokens. Using the files is as easy as setting the correct locale and default domain for your application. Then output is just a basic echo away.

In a new post over on CodeForest.net there's a guide from Zvonko Biskup about using the multi-language support in the Zend Framework, specifically implementing gettext support.

We can not imagine a modern web application without a multi language support. I will show you how easy it is to setup usage of multiple languages in Zend Framework and how to setup some basic language routes (handy for SEO stuff). The Zend Framework offers many ways for you to store your translated strings. It could be an array, a CSV or XML file or you could use gettext which we will be using today.

He introduces the topic by answering the question "why gettext?" with two reasons - the simplicity of editing the gettext files and the fact that Apache caches the resulting ".mo" files. He includes the code to set up a Zend_Translate object in your bootstrap and calling the "translate()" method in your views to handle the hard work. He briefly touches on using PoEdit to work with the gettext files and how to drop those into your ZF application's structure to make them available. Finally, he sets up some automatic routing you can easily use to switch languages based on something like a cookie or session value.