Formulaire multilingue : PoEdit et les chaines dynamiques

Bonjour à tous,

Je rencontre un petit soucis au niveau de la création d'un formulaire de login multilingue utilisant la librairie Zend_Framework. Ou plus précisément avec PoEdit.

Voilà une méthode de ma classe de création de formulaire bien entendu héritée de Zend_Form.

Code:

---

1 2 3 4 5 6 7 8 9

public function translate($translate) { foreach($this->config->elements as $key => $value) { if($translate->isTranslated("usersLogin_" . ucfirst($key))) $this->username->setLabel($translate->translate("usersLogin_" . ucfirst($key))); } }

---

La variable $this->config contient un objet de type Zend_Config_Ini(). Le but de cette fonction est de lister tous les éléments du fichier de configuration (.ini) définissant le formulaire et de remplacer les labels initiaux par les labels traduits s'ils existent ($translate est un objet Zend_Translate, adapatateur gettext).

Cette fonction n'a aucun problème, je l'ai mise à des fins de compréhension. Le problème vient de PoEdit, il détecte automatiquement les chaines à traduire dans l'application mais n'arrive pas à détecter les chaines dynamiques comme celles retournées par ma fonction çi-dessus.

Exemple : dans mon fichier .ini je définit trois champs username, password, submit. Donc mes clés PoEdit souhaitées sont usersLogin_Username, usersLogin_Password, usersLogin_Submit... Seulement voilà, PoEdit ne semble pas "exécuter" le code et me retourne une clé unique usersLogin_. Inutile dans mon cas.

Je précise que j'ai aussi testé la boucle sans la condition afin d'être sûr que toutes les chaines soient traitées.

De même afin de tester ma fonction j'ai utilisé les clés souhaitées (usersLogin_***) dans une vue afin qu'elles soient détectées par PoEdit puis je les ait supprimées de mon application. Le changement se fait bien, ma fonction n'est donc pas en cause.

PoEdit est-il incapable de détecter les chaines dynamiques? Y-a-t'il un autre éditeur qui en serait capable? Peut-on ajouter manuellement une clé/entrée/id de traduction dans PoEdit? Dans ce cas est-il possible de les verrouiller afin qu'il ne passe pas en "Chaînes obsolètes" à chaque mise à jour du catalogue?

Merci pour votre aide,

Bonne journée,

Smiff.

As-tu essayer de concaténer à l'avance ?

Code:

---

1 2 3 4 5 6 7 8 9 10

public function translate($translate) { foreach($this->config->elements as $key => $value) { $userLogin = 'usersLogin_'.ucfirst($key); if($translate->isTranslated($userLogin)) $this->username->setLabel($translate->translate($userLogin)); } }

---

Pas idiot comme idée, j'y avais pas pensé... malheureusement ça ne règle le problème qu'à moitié. La moitié la moins importante.

Avant il ne détectait pas les chaines souhaitées et préfixées par usersLogin_ et en plus il m'ajoutait la chaine usersLogin_ dans la liste des chaines à traduire.

Maintenant il ne prends au moins plus en compte le préfixe seul usersLogin_, par contre toujours pas de détection des chaines "dynamiques".

Au passage j'ai fait un autre test, j'ai enlevé la condition isTranslated() au cas ou PoEdit interprètait quand même le code, ce qui l'aurait amené à ne jamais rencontrer l'instruction translate et donc à ne pas proposer de traduction et ainsi de suite. Je pense que le test était inutile car PoEdit ne semble pas exécuter le code de la page mais juste en lire le contenu.

Merci en tous cas mais visiblement la solution n'est pas suffisante ;)

Personnellement j'utilise TMX, et que je fais une translation, je ne passe pas un string , mais bien une constante comme ceci

Code:

---

1 2	$translate->_(mon_mot);

---

peut-être que comme ceci

Code:

---

1 2 3 4 5 6 7 8 9 10

public function translate($translate) { foreach($this->config->elements as $key => $value) { $mot = ucfirst($key); if($translate->isTranslated("usersLogin_" . ucfirst($key))) $this->username->setLabel($translate->translate(usersLogin_.$mot)); } }

---

J'avais utilisé Tmx au début mais à l'usage je trouve que GetText est plus pratique. En fait l'intérêt réside dans la détection automatique des variables à traduire par PoEdit je trouve ça pratique. Même si mon problème actuel vient mettre un bémol à celà.

J'ai longtemps hésité, Tmx est plus facilement éditable pour un codeur mais PoEdit produit des fichiers compilés que j'estime plus sûrs qu'un xml (même si l'utilisateur n'y a théoriquement pas accès dans une application de type mvc doublé d'une protection par .htaccess adéquate).

La solution ne fonctionne pas non plus, là c'est carrément une erreur php tandis que PoEdit continue à ignorer ces chaînes. Mais merci pour la suggestion :)

Bonjour Smiff,

Dans mon application, j'utilise aussi gettext + poedit.
Comme tu l'as bien compris, poedit est incapable d'exécuter ton code pour connaître la valeur d'une variable.
C'est tout à fait normal, car pour des applications complexes, il devrait exéctuer toute l'application et non un seul fichier php. Ce qui est quasiment impossible (ou vraiment complexe).

La traduction de site est toujours un problème épineux.
Dans mon cas, j'utilise la traduction gettext seulement pour les bouts de text statiques directement inclus dans mes vues. Pour les textes dynamiques les traductions sont gardées au niveau de la base de données.

Maintenant ton problème vient principalement du fait que tu génères tes forms à partir de fichier ini. Ce qui n'est peut-être pas le mieux pour la traduction automatisée.

Tu peux très bien avoir tes forms ou elements de form dans des classes php. Qui elles contiennes la function reconnue par poedit.

exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class My_Form_Element_Password extends Zend_Form_Element_Password { public function init() { // Récupère l'objet translate de ZF créé dans le bootstrap $translator = Zend_Registry::get('Zend_Transalte');   $this->setLabel($translator->translate('Mot de passe')) ->setAttribs(array( 'maxlength' => 255 )) ->setRequired(true) ->addValidators( array('Alnum', array('StringLength', true, array(4, 25))) ); } }

---

Note : J'ai configuré poedit pour qu'il prenne en compte la fonction translate() et pas _().

Sinon, il te reste encore une solution.
Tu inclus directement les traductions dans ces fichiers.

J'espère que ca t'aidera ;)

Bonsoir,

J'avais opté pour ta solution avec le système de classes à l'origine et ça fonctionnait parfaitement effectivement.

Mais comme j'aime la complexité :lol: le but était de ne faire qu'une classe de formulaire capable de générer des formulaires différents (sans pour autant faire une méthode par formulaire) à partir de fichier que des non programmeurs pouvaient modifier relativement facilement et à volontée (les .ini, même si des .csv seraient encore mieux).

Peut-être que je vais quand même revenir à cette solution finalement avec ton idée d'utiliser une base de donnée je devrais pouvoir bricoler un truc.

Note au passage : J'ai contacté l'auteur de PoEdit pour lui poser la question directement (qui ne tente rien n'a rien)... résultat... c'est incroyable ce que certaines personnes peuvent être imbues de leur personne et incapables de transmettre leur savoir ou au moins de répondre sans condescendance. Il en ressort quand même une chose intéressante (pour moi), il faudrait que je maitrise mieux l'api gettext de php. Qui sait, peut-être que si je comprends bien le système je ferait mon propre programme ;)

Merci pour votre aide à tous les deux, je pense que je devrais m'en sortir avec ça. Si je trouve quelque chose par la suite je mettrais une suite à ce post. Ca existe le statut "[Plus ou moins résolu]" :mouarf:

Bonne soirée,

Smiff.

Salut Smiff,

En gros, si tu veux que tes formulaires soient créé dynamiquement grâce à une configuration faite par des non-programmeurs. La meilleure solution est de garder leurs propriétés en base de données ou de prévoir un champ par langue pour les labels, c'est pas très difficle à mettre en oeuvre. Mais le plus classe, c'est la db plus une interface web admin évidemment.

A+,
Olivier

Bonne idée, bon ben pas mal de dev en perspective :D