Discussion :

[Invité]

Bonjour,

J'utilise admin generator pour mon interface d'administration.

Mes formulaires contiennent des listes déroulantes (<select>...</select>).

Les noms de leurs options correspondent aux champs "name" des objets récupérés en base de données, donc ils ne sont pas traduits.

Sans créer une table localisée dans ma base, comment est-il possible de localiser ces noms d'options de listes déroulantes ?

Merci.

[bilbonec]

Bonjour,

Lorsque tu affiches dans ton template tes champs de <select>, il est alors nécessaire d'appeler la fonction d'internationalisation "__($field)".

(regarde les templates générés par l'admin-gen, tu en as plein d'exemples).

Cette méthode nécessite que tu définisses des fichiers XML de traduction (regarde par exemple dans sfDoctrineGuardPlugin/i18n).

Niveau configuration de tout ça, je ne sais plus comment ça se passe mais je sais que c'est très simple (genre tout mettre dans un répertoire i18n de ton projet, en respectant les conventions de nommage). Une recherche sur le net t'apportera toutes les réponses !

[Herode]

J'ai vu qu'il y a aussi une option non documentée (à ma connaissance) translate_choices dans la classe sfWidgetFormChoiceBase (dont descend par exemple sfWidgetFormSelect ou les autres widgets gérant des listes déroulantes).

A vue de nez il faut passer au sfWidgetFormSchemaFormatter un pointeur de fonction sur la fonction de traduction et l'adresse d'un catalogue. Je suppose que par exemple passer un pointeur sur __() et le path du .xml du dossier i18n ad hoc pourrait marcher.

Comme l'option est à true par défaut, je suis même tenté de penser que le pointeur sur __() et sur le dossier i18n sont renseignés par défaut, il ne resterait alors qu'à savoir dans quel .xml il faut placer ses chaines de traduction.

Quelqu'un a testé cette option et pourrait nous en dire plus ?

[Invité]

Bonjour, merci pour vos réponses.

Bilbonec, j'ai déjà regardé les templates générés par l'admin generator. La génération des champs se fait dans le partial _form_field.php par l'appel de la méthode render sur le widget :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php echo $form[$name]->render($attributes instanceof sfOutputEscaper ? $attributes->getRawValue() : $attributes) ?>

J'ai navigué dans le code des classes sfFormField, sfWidgetForm, sfWidgetFormSelect, etc. Cela fait explorer le code de base de symfony, hors ce n'est pas le sujet ici. Il faut peut-être surcharger la méthode render pour les widgets de type select ? Si oui, comment s'y prendre ? Où se trouvent spécifiquement les "echo" qui sortent le code HTML ? N'y a-t-il pas plus simple en agissant directement au niveau de l'admin générator, ou des classes sfObjectForm de mon modèle ?

Utiliser l'i18n dans symfony n'est pour moi pas un problème. J'ai localisé toutes mes pages, mais il reste des éléments de formulaire qui font fi de mes fichiers de langues XML, ce qui est très frustrant.

Herode, je vais regarder cette piste, merci. Mais encore une fois on semble descendre bien bas dans le code de symfony, alors qu'il s'agit tout de même d'une fonctionnalité très haut niveau.

[bilbonec]

Du coup, tu as testé de remplacer ce morceau de template par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
<?php if ($attributes instanceof sfOutputEscaper): ?>
    <?php echo __($attributes->getRawValue()) ?>
<?php else: ?>
    <?php echo __($attributes) ?>
<?php endif; ?>

?

Cela devrait marcher.

[Invité]

Malheureusement ça ne fonctionne pas, même en explicitant le catalogue choisi et en reportant le fichier de langue correspondant jusque dans le dossier i18n du module courant... D'ailleurs il faut appeler la fonction __() avec $form[$name]->render($attributes) en argument, et non simplement $attributes.

En fait, voici ce que j'envoie à traduire au helper i18n avec cette méthode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<select name="subscription[duration_unit]" id="subscription_duration_unit">
<option value="3">day</option>
<option value="2">month</option>
<option value="1">year</option>
</select>

Le code ci-desssus est obtenu avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php echo '<pre>'.__(esc_specialchars($form[$name]->render($attributes->getRawValue()), array(), 'messages')).'</pre>' ?>

Dans cet exemple, je veux traduire les mots "day", "month" et "year".

Je peux toujours redéfinir le __toString() du modèle DuratioUnit, mais c'est très moche et pas vraiment compatible avec i18n (à moins d'appeler le helper i18n dans le modèle, ce qui est encore plus moche et déconseillé).

[bilbonec]

Dans ce cas, j'aurais tendance à te conseiller comme Hérode de regarder l'option 'formatter' pour formater le rendu du widget à ta guise.

Cela t'oblige à définir un nouveau widget qui étend de celui que tu utilises actuellement, et de juste redéfinir la méthode qu'il te faut.

Mais encore une fois on semble descendre bien bas dans le code de symfony, alors qu'il s'agit tout de même d'une fonctionnalité très haut niveau.

C'est malheureusement le problème souvent avec les formulaires Symfony. Ils ont eu la très mauvaise idée de gérer leur rendu de widget dans le code PHP (et donc de mélanger les couches M et V du modèle MVC) alors que s'ils avaient géré TOUT leur rendu avec des templates, tous ces problèmes ne se seraient pas posés !!