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.

WordPress itself is translated to many languages and people can use it in their preferred language. But this is not the case with themes, plugins, and other front-end customizations. [...] The purpose of this article is to show you how to translate properly any theme or plugin by using internationalization and localization methods. In brief, internationalization (i18n) deals with making sure strings of text are wrapped in specific function calls.

He starts by introducing the PHP functions (and configuration) you'll need to get the localization support up and running in your plugin, including a few examples of how to translate a string. Also included into the post is an introduction to using the Poedit software to create the different translation files.

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.