Programmer's Reference Guide
| Introduction |
Adaptateurs pour Zend_Translate
Zend_Translate peut manipuler différents adaptateurs pour la traduction. Chaque adaptateur a ses propres avantages et inconvénients. Ci-dessous vous trouverez la liste complète de tous les adaptateurs supportés pour la traduction des fichiers sources.
| Adaptateur | Description | Utilisation |
|---|---|---|
| Tableau (array) | Utilise les tableaux PHP | Petites pages ; l'utilisation la plus simple ; seulement pour les programmeurs |
| Csv | Utilise les fichiers à séparation par virgule (*.csv/*.txt) | Format simple de fichier texte ; rapide ; problèmes possibles avec les caractères Unicode |
| Gettext | Utilise les fichiers binaires gettext (*.mo) | Norme GNU pour Linux ; thread-safe ; besoin d'outils pour la traduction |
| Ini | Utilise de simples fichiers ini (*.ini) | Format simple de fichier texte ; rapide ; problèmes possibles avec les caractères Unicode |
| Tbx | Utilise les fichiers d'échange termbase (*.tbx/*.XML) | Standard industriel pour des chaînes partagées entre les applications ; format XML |
| Tmx | Utilise les fichiers tmx (*.tmx/*.XML) | Industriellement compatible avec la traduction partagée d'application ; format XML ; lisible par l'homme |
| Qt | Utilise les fichiers qt linguist (*.ts) | Framework pour les applications mutualisées ; format XML ; lisible par l'homme |
| Xliff | Utilise les fichiers xliff (*.xliff/*.XML) | Un format plus simple que TMX mais lié à lui ; format XML ; lisible par l'homme |
| XmlTm | Use xmltm (*.XML) files | Standard industriel pour la traduction de type XML ; format XML ; lisible par l'homme |
| Autres | *.sql | Différents adaptateurs pourront être implémentés dans l'avenir. |
Comment décider quel adaptateur de traduction utiliser ?
Vous devrez décider quel adaptateur vous voulez utiliser avec Zend_Translate. Fréquemment, des critères externes tels qu'une condition du projet ou une exigence du client détermine ceci pour vous, mais si vous êtes en position de le faire vous-même, les conseils suivants peuvent simplifier votre décision.
Note: En choisissant votre adaptateur vous devriez également prendre en compte l'encodage utilisé. Même si Zend Framework déclare UTF-8 comme encodage par défaut, il vous sera parfois nécessaire d'utiliser un autre encodage. Zend_Translate ne changera pas l'encodage défini dans votre fichier source ce qui veut dire que si votre source Gettext est construite en ISO-8859-1, il retournera les chaînes dans cet encodage sans les convertir. Il existe une seule restriction :
Quand vous utilisez des sources basées sur le format XML comme TMX ou XLIFF vous devez définir l'encodage dans l'en-tête des fichiers XML, car tout fichier XML sans définition d'encodage sera traité par défaut en UTF-8 par un analyseur XML. Vous devez aussi prendre en compte que les encodages des fichiers XML sont limités aux encodages supportés par PHP, c'est-à-dire UTF-8, ISO-8859-1 and US-ASCII.
Zend_Translate_Adapter_Array
L'adaptateur de type tableau est l'adaptateur qui est le plus simple à utiliser pour les programmeurs. Mais quand vous avez de nombreuses chaînes de traduction ou beaucoup de langues vous devriez penser à un autre adaptateur. Par exemple, si vous avez 5000 chaînes de traduction, l'adaptateur tableau n'est probablement pas le choix le plus approprié pour vous.
Vous devriez seulement utiliser cet adaptateur pour de petits sites avec quelques langues, et si vous (ou votre équipe de programmeur) créez les traductions vous-même.
Zend_Translate_Adapter_Csv
L'adaptateur Csv est l'adaptateur qui est le plus simple à utiliser pour les clients. Les fichiers CSV sont lisibles par les éditeurs de texte standard, mais souvent les éditeurs de texte ne supportent pas les jeux de caractères utf8.
Vous devriez utiliser cet adaptateur seulement si votre client veut faire les traductions lui-même.
Note: Prenez garde que l'adaptateur Csv a des problèmes quand vos fichiers Csv ont un encodage différent que celui de votre environnement. Ceci est du à un bug de PHP lui-même qui ne sera pas corrigé avant la PHP 6.0 (http://bugs.php.net/bug.php?id=38471). Vous devez donc faire attention que l'adaptateur Csv ne gère pas la locale à cause d'une restrictions PHP.
Zend_Translate_Adapter_Gettext
L'adaptateur Gettext est l'adaptateur qui est utilisé le plus souvent. Gettext est un format de source de traduction qui a été présenté par GNU, et est maintenant employé dans le monde entier. Il n'est pas lisible pour l'homme, mais il y a plusieurs outils gratuiciels (par exemple, » POEdit), qui sont très utiles. L'adaptateur Zend_Translate_Gettext n'est pas implémenté en utilisant l'extension gettext de PHP. Vous pouvez utiliser l'adaptateur Gettext même si vous n'avez pas installer l'extension gettext de PHP. En outre l'adaptateur est "thread-safe" alors que l'extension gettext de PHP ne l'est pas actuellement.
La plupart des personnes utiliseront cet adaptateur. Avec les outils disponibles, la traduction professionnelle est très simple. Mais les données de gettext sont stockées dans un format compréhensible par une machine, qui n'est pas lisible sans outils.
Zend_Translate_Adapter_Ini
L'adaptateur Ini est un adaptateur qui peut être directement utiliser par les clients. Les fichiers INI sont lisibles par les éditeurs de texte standard, mais souvent les éditeurs de texte ne supportent pas les jeux de caractères utf8.
Vous devriez utiliser cet adaptateur seulement si votre client veut faire les traductions lui-même. N'utilisez pas cet adaptateur comme source de traduction générique.
Regression in PHP 5.3
Prior to PHP 5.3, parse_ini_file() and parse_ini_string() handled non-ASCII characters within INI option keys worked without an issue. However, starting with PHP 5.3, any such keys will now be silently dropped in the returned array from either function. If you had keys utilizing UTF-8 or Latin-1 characters, you may find your translations no longer work when using the INI adapter. If this is the case, we recommend utilizing a different adapter.
Zend_Translate_Adapter_Tbx
L'adaptateur Tbx est un adaptateur qui sera utilisé par les clients qui utilisent déjà le format TBX pour leur système de traduction interne. Tbx n'est pas un format de traduction standard, mais plus une collection de chaînes de caractère sources déjà traduites et pré-traduites. Quand vous utilisez cet adaptateur vous devez être sûrs que toute votre chaîne de caractère source nécessaire est traduite. TBX est un fichier basé sur le format XML et un format complètement nouveau. XML des fichiers sont lisibles par l'homme, mais l'analyse syntaxique n'est pas aussi rapide qu'avec des fichiers gettext.
Cet adaptateur est parfait pour les sociétés dont les fichiers source pré-traduits existent déjà. Les fichiers sont lisibles par l'homme et sont indépendants de système.
Zend_Translate_Adapter_Tmx
L'adaptateur Tmx est l'adaptateur qui sera employé par la plupart des clients qui ont des systèmes multiples qui emploient la même source de traduction, ou quand la source de traduction doit être indépendante du système. TMX est un format basé sur le format XML, qui est annoncé pour être le prochain standard industriel. Les fichiers de XML sont lisibles par l'homme, mais l'analyse n'est pas aussi rapide qu'avec des fichiers gettext.
La plupart des moyennes à grandes entreprises utilisent cet adaptateur. Les fichiers sont lisibles par l'homme et sont indépendants du système.
Zend_Translate_Adapter_Qt
L'adaptateur Qt est destiné à tous les clients qui ont des fichiers TS faits par QtLinguist comme source de traduction. QT est un fichier basé sur le format XML. Les fichiers XML sont humainement lisible, mais l'analyse syntaxique n'est pas si rapide qu'avec des fichiers gettext.
Plusieurs grands acteurs ont construit leur logiciel sur le framework QT. Les fichiers sont lisibles par l'homme et indépendants du système.
Zend_Translate_Adapter_Xliff
L'adaptateur Xliff est l'adaptateur qui sera employé par la plupart des clients qui veulent avoir des fichiers XML mais n'ont pas d'outils pour TMX. XLIFF est basé sur le format XML et est lié à TMX mais est plus simple car il ne supporte pas toutes ses possibilités. Les fichiers XML sont lisibles par l'homme, mais l'analyse n'est pas aussi rapide qu'avec des fichiers gettext.
La plupart des moyennes entreprises utilisent cet adaptateur. Les fichiers sont lisibles par l'homme et sont indépendants du système.
Zend_Translate_Adapter_XmlTm
L'adaptateur XmlTm est l'adaptateur qui sera utilisé par les clients qui font leur mise en page eux-mêmes. XmlTm est un format qui permet à la source HTML complète d'être incluse dans la source de traduction, donc la traduction est couplée avec la mise en page. XmlTm est un fichier basé sur le format XML, qui est proche de XLIFF, mais qui n'est pas aussi simple à lire.
Cet adaptateur devrait être seulement utilisé quand des fichiers source existent déjà. Les fichiers sont lisibles par l'homme et sont indépendants du système.
Intégrer ses propres adaptateurs
Zend_Translate vous permet d'intégrer et d'utiliser vos propres classes d'adaptateurs. Elles peuvent être utilisées commes les classes standards qui sont déjà incluses dans Zend_Translate.
Toute classe d'adaptateur que vous voulez utiliser avec Zend_Translate doit être une sous-classe de Zend_Translate_Adapter. Zend_Translate_Adapter est une classe abstraite qui définit déjà tout ce qui est nécessaire pour la traduction. Ce qui doit être fait par vous, est la définition du lecteur des données traduites.
L'usage du préfixe "Zend" devrait être limité à Zend Framework. Si vous étendez Zend_Translate avec votre propre adaptateur, vous devriez le nommer "MonEntreprise_Translate_Adapter_MonFormat". Le code suivant montre un exemple de la manière dont une classe d'adaptateur personnalisée peut être implémentée :
- try {
- $translate = new Zend_Translate(
- 'adapter' => 'MonEntreprise_Translate_Adapter_MonFormat',
- 'content' => '/path/to/translate.xx',
- 'locale' => 'en',
- 'myoption' => 'myvalue'
- )
- );} catch (Exception $e) {
- // Fichier non trouvé, pas de classe d'adaptateur...
- // Echec de l'application
- }
Améliorer les performances de tous les adaptateurs
Zend_Translate vous permet d'utiliser en interne Zend_Cache pour accélérer le chargement des sources de traduction. Cela devient très pratique si vous utilisez beaucoup de sources de traduction ou des formats source vastes comme des fichiers au format XML.
Pour utiliser le cache, vous devez juste fournir un objet de cache à la méthode Zend_Translate::setCache(). Elle prend une instance de Zend_Cache comme seul paramètre. En outre si vous utilisez n'importe quel adaptateur direct, vous pouvez employer la méthode setCache(). Par commodité, il existe des méthodes statiques getCache(), hasCache(), clearCache() et removeCache().
- $cache = Zend_Cache::factory('Core',
- 'File',
- $frontendOptions,
- $backendOptions);
- Zend_Translate::setCache($cache);
- $translate = new Zend_Translate(
- 'adapter' => 'gettext',
- 'content' => '/path/to/translate.mo',
- 'locale' => 'en'
- )
- );
Note: Vous devez paramétrer le cache avant d'utiliser ou d'initialiser tout adaptateur ou instance de Zend_Translate. Sinon votre source de traduction ne sera pas mise en cache tant que vous n'aurez pas ajouté une nouvelle source avec la méthode addTranslation().
| Introduction |
Add A Comment
Please do not report issues via comments; use the ZF Issue Tracker.
If you have a JIRA/Crowd account, we suggest you login first before commenting.
Comments
Zend_Translate only except one parameter as an array.
In 10.2 it works like the example.
Lorsqu'on utilise des caractères accentués en ISO-8859... avec le format CSV (sous Excel) et Zend_Translate_Adapter_Csv avec PHP5, l'encodage n'est pas détecté (comme expliqué plus haut) et les accents s'affichent mal.
Il existe une solution simple pour éviter ce problème (en attendant PHP6) :
- Open Office vous permet d'ouvrir des fichiers CSV au format Unicode (UTF-8) ou Europe (ISO-8859-15 par ex) et de les enregistrer avec l'encodage voulu. Il convertit donc les accents automatiquement : par exemple, é en é
Sinon on pourrait surcharger la classe Zend_Translate_Adapter_Csv et y ajouter une méthode utf8_decode par exemple...
De cette façon vous pouvez facilement donner à votre client les traductions et les réintégrer dans votre application.
Cordialement
Hi,
To avoid encoding and UTF_8 character sets problems, with CSV format, you can use Open Office to convert your file into encoding of your choice : UTF_8 to ISO, ISO to UTF_8...
Best regards
as I worked for 7 years as an IT-leader in a translation company I must admitt, that Zend_Translate is a good step, but especially the TMX and XLIFF-Adapters are far away from beeing able to handle TMX and XLIFF-data correctly. Everything works fine as long as you do not have so called inline elements (see oasis xliff spec i. e.). As soon as you need them, i. e. if you have a string to translate like the following:
"'%value%' is now valid resetHash"
it would be necessary i. e. in xliff to wrap the variable-Part in the string in an inline Tag. The reason for this is, that it _has_ to be inside the translated string, because in some languages it for sure must not be placed at the beginning of the sentence, but i. e. in the middle or at the end. Therefore it has to be inside of the translated string, but as a programmer you want to be sure, that the translator for example does not translate the word "value" - but online place the string '%value%' in the correct position. Therefore you have the inline elements in professional translation formats like xliff (which is in reality not more simple as tmx like stated above, but the more standard and more modern but sometimes even complexer format than tmx).
Therefore the sentence above wrapped in an xliff unit shoulld look like the following:
<trans-unit id='uniqId'><source><ph equiv-text='The returned form Value'>'%value%'</ph> is no valid resetHash</source><target><ph equiv-text='The returned form Value'>'%value%'</ph> ist kein gültiger resetHash</target></trans-unit>
But if you do things like that in your xliff-File, the xliff-Adapter of ZF is not able to handle it correctly. What is does is a string to string comparison of the string you have in your Zend_Translate->_(''); expression i. e. Zend_Translate->_("'%value%' is now valid resetHash"); with the string between the source-Tags. To get a match from the adapter for my to be translated string above, the corresponding xliff-source-Tag has to look like this:
<source>'%value%' is no valid resetHash</source>
But this way the variable '%value%' is not protected and therefore likely to be translated in a professional translation process, where translators should be experts in spoken languages but not in programming languages.
Would be great to have support for inline-Tags especially in xliff, which is the future, while TMX is the past.
Regards, Marc
As an example, take a look at MediaWiki projects (Wikipedia too) and TranslateWiki site. They are using PHP arrays and have more than 150 languages and thousands of variables with short and long strings. And I haven't heard any complains.
So, again, please add a real reason next to that above statement.
Thanks