Programmer's Reference Guide
| Adapters for Zend_Translate |
Using Translation Adapters
The next step is to use the adapter within your code.
Пример #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.
Пример #2 Example of multi-lingual PHP code
$translate = new Zend_Translate('gettext', '/my/path/source-de.mo', 'de');
$translate->addTranslation('/path/to/translation/fr-source.mo', '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 integrate Zend_Translate into your own code.
Create a new Zend_Translate object and define the base adapter:
$translate = new Zend_Translate
'gettext',
'/path/to/translation/source-de.mo',
'de'
);
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";
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"));
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";
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
/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 tendious 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.
Creating Array source files
Array source files are plain arrays. But you have to define them manually since there is no tool to aid this. But because they are so simple, it's the fastest way to look up messages if your code works as expected. It's generally the best adapter to get started with translation business.
$english = array(
'message1' => 'message1',
'message2' => 'message2',
'message3' => 'message3');
$german = array(
'message1' => 'Nachricht1',
'message2' => 'Nachricht2',
'message3' => 'Nachricht3');
$translate = new Zend_Translate('array', $english, 'en');
$translate->addTranslation($deutsch, 'de');
Since release 1.5 it is also supported to have arrays included within an external file. You just have to provide the filename and Zend_Translate will automatically include it and look for the array. See the following example for details:
// myarray.php
return array(
'message1' => 'Nachricht1',
'message2' => 'Nachricht2',
'message3' => 'Nachricht3');
// controller
$translate = new Zend_Translate('array', '/path/to/myarray.php', 'de');
Замечание: Files which do not return an array will fail to be included. Also any output within this file will be ignored and suppressed.
Creating Gettext source files
Gettext source files are created by GNU's gettext library. There are several free tools available that can parse your code files and create the needed gettext source files. These have the extension *.mo and they are binary files. An open source tool for creating the files is » poEdit. This tool also supports you during the translation process itself.
// We accume that we have created the mo files and translated them
$translate = new Zend_Translate('gettext', '/path/to/english.mo', 'en');
$translate->addTranslation('/path/to/german.mo', 'de');
As you can see the adapters are used exactly the same way, with one small difference: change array to gettext. All other usages are exactly the same as with all other adapters. With the gettext adapter you no longer have to be aware of gettext's standard directory structure, bindtextdomain and textdomain. Just give the path and filename to the adapter.
Замечание: You should always use UTF-8 as source encoding. Otherwise you will have problems when using two different source encodings. E.g. one of your source files is encoded with ISO-8815-11 and another one with CP815. You can set only one encoding for your source file, so one of your languages probably will not display correctly.
UTF-8 is a portable format which supports all languages. When using UTF-8 for all languages, you will eliminate the problem of incompatible encodings.
Many gettext editors add adapter informations as empty translation string.
This is the reason why empty strings are not translated when using the
gettext adapter. Instead they are erased from the translation table and
provided by the getAdapterInfo() method. It will return
the adapter informations for all added gettext files as array using the
filename as key.
// Getting the adapter informations
$translate = new Zend_Translate('gettext', '/path/to/english.mo', 'en');
print_r($translate->getAdapterInfo());
Creating TMX source files
TMX source files are a new industry standard. They have the advantage of being XML files and so they are readable by every editor and of course by humans. You can either create TMX files manually with a text editor, or you can use a special tool. But most tools currently available for creating TMX source files are not freely available.
Пример #3 Example TMX file
<?xml version="1.0" ?>
<!DOCTYPE tmx SYSTEM "tmx14.dtd">
<tmx version="1.4">
<header creationtoolversion="1.0.0" datatype="winres" segtype="sentence"
adminlang="en-us" srclang="de-at" o-tmf="abc"
creationtool="XYZTool" >
</header>
<body>
<tu tuid='message1'>
<tuv xml:lang="de"><seg>Nachricht1</seg></tuv>
<tuv xml:lang="en"><seg>message1</seg></tuv>
</tu>
<tu tuid='message2'>
<tuv xml:lang="en"><seg>message2</seg></tuv>
<tuv xml:lang="de"><seg>Nachricht2</seg></tuv>
</tu>
$translate = new Zend_Translate('tmx', 'path/to/mytranslation.tmx', 'en');
TMX files can have several languages within the same file.
All other included languages are added automatically,
so you do not have to call addLanguage().
If you want to have only specified languages from the source translated
you can set the option 'defined_language' to true.
With this option you can add the wished languages explicitly with
addLanguage(). The default value for this option is to add all
languages.
Creating CSV source files
CSV source files are small and human readable. If your customers want to translate their own, you will probably use the CSV adapter.
Пример #4 Example CSV file
#Example csv file message1;Nachricht1 message2;Nachricht2
$translate = new Zend_Translate('csv', '/path/to/mytranslation.csv', 'de');
$translate->addTranslation('path/to/other.csv', 'fr');
There are three different options for the CSV adapter.
You can set 'delimiter', 'limit' and
'enclosure'.
The default delimiter for CSV string is ';', but
with the option 'delimiter'
you can decide to use another one.
The default limit for a line within a CSV file is '0'. This means
that the end of a CSV line is searched automatically. If you set
'limit' to any value, then the CSV file will be
read faster, but any line exceeding this limit will be truncated.
The default enclosure to use for CSV files is '"'. You can
set a different one using the option 'enclosure'.
Пример #5 Second CSV file example
# Example CSV file "message,1",Nachricht1 message2,"Nachricht,2" "message3,",Nachricht3
$translate = new Zend_Translate(
'csv',
'/path/to/mytranslation.csv',
'de',
array('delimiter' => ','));
$translate->addTranslation('/path/to/other.csv', 'fr');
Creating INI source files
INI source files are human readable but normally not very small as they also include other data beside translations. If you have data which shall be editable by your customers you can use the INI adapter.
Пример #6 Example INI file
[Test] ;TestPage Comment Message_1="Nachricht 1 (de)" Message_2="Nachricht 2 (de)" Message_3="Nachricht :3 (de)"
$translate = new Zend_Translate('ini', '/path/to/mytranslation.ini', 'de');
$translate->addTranslation('/path/to/other.ini', 'it');
INI files have several restrictions. If a value in the ini file contains any
non-alphanumeric characters it needs to be enclosed in double-quotes (").
There are also reserved words which must not be used as keys for ini files.
These include: null, yes, no, true,
and false. Values null, no and false results
in "", yes and true results in 1. Characters {}|&~