Using Translation Adapters
The next step is to use the adapter within your code.
Example #1 Example of single-language PHP code
The example above shows some output with no support for translation. You probably write your code in your native language. Generally you need to translate not only the output, but also error and log messages.
The next step is to integrate Zend_Translate into your existing code. Of course it is much easier if you had already written your code with translation in mind, than changing your code afterwards.
Example #2 Example of multi-lingual PHP code
- $translate = new Zend_Translate(
- 'adapter' => 'gettext',
- 'content' => '/my/path/source-de.mo',
- 'locale' => 'de'
- 'content' => '/path/to/translation/fr-source.mo',
- 'locale' => 'fr'
- print $translate->_("Example") . "\n";
- print $translate->_("Here is line one") . "\n";
- print "\n";
- print $translate->_("Here is line two") . "\n";
Now let's take a deeper look into what has been done and how to integrate Zend_Translate into your own code.
Create a new Zend_Translate object and define the base adapter:
- $translate = new Zend_Translate
- 'adapter' => 'gettext',
- 'content' => '/path/to/translation/source-de.mo',
- 'locale' => 'de'
In this example we chose the Gettext Adapter. We place our file source-de.mo into the directory /path/to/translation. The gettext file will have German translation included, and we also added another language source for French.
The next step is to wrap all strings which are to be translated. The simplest approach is to have only simple strings or sentences like this:
Some strings do not needed to be translated. The separating line is always a separating line, even in other languages.
Having data values integrated into a translation string is also supported through the use of embedded parameters.
Instead of print(), use the printf()
function and replace all parameters with
The first is
%1\$s, the second is
and so on. This way a translation can be done without knowing
the exact value. In our example, the date is always the actual day,
but the string can be translated without the knowledge of the actual
Each string is identified in the translation storage by a message ID. You can use message IDs instead of strings in your code, like this:
But doing this has several disadvantages:
You can not see what your code should output just by viewing your code.
Also you will have problems if some strings are not translated. You must always keep in mind how translation works. First Zend_Translate checks whether the specified language has a translation for the given message ID or string. If no translation string has been found it refers to the next lower level language as defined within Zend_Locale. So "de_AT" becomes "de" only. If there is no translation found for "de" either, then the original message is returned. This way you always have an output, even in case the message translation does not exist in your message storage. Zend_Translate never throws an error or exception when translating strings.
Translation Source Structures
Your next step is to create the translation sources for the languages you want to translate. Every adapter is created its own way as described here, but there are common features applicable for all adapters.
You have to decide where to store your translation source files. Using Zend_Translate you are not restricted in any way. The following structures are preferable:
Single structured source
Positive: all source files for every languages are stored in one directory. No splitting of related files.
Language structured source
Positive: Every language is stored in their own directories. Easy translation, as every language team has to translate only one directory. Also the usage of multiple files is transparent.
Application structured source
Positive: all source files for every language are stored in one directory. No splitting of related files.
Negative: having multiple files for the same language can be problematic.
Gettext structured source
Positive: existing gettext sources can be used without changing structure.
Negative: having sub-sub directories may be confusing for people who have not used gettext before.
File structured source
Positive: translation files are localted near their source.
Negative: too many and also small translation files result in being tedious to translate. Also every file has to be added as translation source.
Single structured and language structured source files are most usable for Zend_Translate.
So now, that we know which structure we want to have, we should create our translation source files.