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.

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.

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.

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.

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.

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.

Mac OSX Lion ships with PHP 5.3.6. [...] These are all very good solutions, but since I prefer to travel light and the version in Lion already comes with a lot of useful extensions, I preferred to go with it.

He shows how to update the default Lion PHP install to include some of the things he needed for his development including:

• setting up the php.ini file
• installing PEAR/PECL
• installing the intl extension
• and a hack to get gettext working (renaming a base function)

If you're a Web developer building an application for global consumption, it's important for you to build in a framework for multi-language support right from the start. Fortunately, there are a number of ready-made components that can help with this task. This article will introduce you to one such component, Zend_Translate, and demonstrate how you can use it to add multi-language support to your PHP application.

There's no "magic bullet" here that'll do the translation for you, but he shows you how to set up the data for the different languages, either in PHP arrays or in translation files, that the Zend_Translate component knows how to use. He also mentions the component's ability to scan a directory tree for language files an detect the language based on a naming convention. He also mentions the "gettext" tool that you can use to generate language files based on a standard GNU format that can be used cross-language with several different tools.

There's lots of other handy bits in the tutorial so I suggest reading if you're thinking about any kind of translation for your site.

I'm just curious what the best practices are for translating your website into another language, to present foreign readers with text in their home lingua -- well, particularly if there are PHP-specific methods to do so. I've stumbled across the pages for GNU gettext and that seems interesting, but I'm curious what people think of it.

Suggestions include manual translation via a human, use a text substitution method two swap out content versions based on language, using language files (and some opinions from others on which of these approaches might work best).

Wikipedia says: Localization is the process of translating a product into different languages or adapting a language for a specific country or region. There are several techniques that developer can use to localize an application. The most common ones are using arrays and gettext. I will try to explain both and how to use them.

They provide code examples for each method - arrays containing literal strings matching one-for-one with their English counterparts and the gettext method where language files are created and handled outside of the codebase. Gettext does require support to be loading into your installation (might not be by default).