The next step is to use the adapter within your code.
Example #1 Example of single-language PHP code
print "Example\n"; print "=======\n"; print "Here is line one\n"; print "Today is the " . date("d.m.Y") . "\n"; print "\n"; print "Here is line two\n";
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( array( 'adapter' => 'gettext', 'content' => '/my/path/source-de.mo', 'locale' => 'de' ) ); $translate->addTranslation( array( 'content' => '/path/to/translation/fr-source.mo', 'locale' => 'fr' ) ); print $translate->_("Example") . "\n"; print "=======\n"; print $translate->_("Here is line one") . "\n"; printf($translate->_("Today is the %1\$s") . "\n", date('d.m.Y')); print "\n"; $translate->setLocale('fr'); print $translate->_("Here is line two") . "\n";
Now let's take a deeper look into what has been done and how to
Zend_Translate into your own code.
Create a new
Zend_Translate object and define the base adapter:
$translate = new Zend_Translate array( '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:
print $translate->_("Example") . "\n"; print "=======\n"; print $translate->_("Here is line one") . "\n";
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.
printf($translate->_("Today is the %1\$s") . "\n", date("d.m.Y"));
Instead of print(), use the printf() function and replace all parameters with %1\$s parts. The first is %1\$s, the second is %2\$s, 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 day.
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:
print $translate->_(1) . "\n"; print "=======\n"; print $translate->_(2) . "\n";
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.
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
So "de_AT" becomes
If there is no translation found for
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
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.
Zend_Translate you are not restricted in any way.
The following structures are preferable:
Single structured source
/application/ /languages/ /languages/lang.en /languages/lang.de /library/
Positive: all source files for every languages are stored in one directory. No splitting of related files.
Language structured source
/application/ /languages/ /languages/en/ /languages/en/first.en /languages/en/second.en /languages/de/ /languages/de/first.de /languages/de/second.de /library
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
/application/ /application/languages/ /application/languages/first.en /application/languages/first.de /application/languages/second.en /application/languages/second.de /library/
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
/application/ /languages/ /languages/de/ /languages/de/LC_MESSAGES/ /languages/de/LC_MESSAGES/first.mo /languages/de/LC_MESSAGES/second.mo /languages/en/ /languages/en/LC_MESSAGES/ /languages/en/LC_MESSAGES/first.mo /languages/en/LC_MESSAGES/second.mo /library/
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
/application/ /application/models/ /application/models/MyModel.php /application/models/MyModel.de /application/models/MyModel.en /application/controllers/ /application/controllers/MyController.php /application/controllers/MyController.de /application/controllers/MyController.en /library/
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
So now, that we know which structure we want to have, we should create our translation source files.