Bonjour,

Après plusieurs recherches, voici la solution la plus élégante que
j'ai pu trouver pour résoudre ce problème.

Tout d'abord, il faut pouvoir surcharger la classe sfModelGenerator de
Symfony.

Pour cela, on copie cette classe dans lib/extended/
sfModelGenerator.class.php.

Dans ce fichier, on renomme la classe sfModelGenerator en
sfPreModelGenerator, puis on ajoute après la déclaration classe
sfModelGenerator qui se contente d'étendre sfPreModelGenerator.

Dans sfModelGenerator, on ajoute la fonction suivante :

  public function getLinkToAction($actionName, $params, $pk_link =
false)
  {
        $return = parent::getLinkToAction($actionName,$params,$pk_link) ;

        if(isset($params['params'])) {
                if(isset($params['params']['confirm'])) {
                        $return = str_replace("'confirm' => '".$params['params']
['confirm']."'","'confirm' => ".'__(\''.$params['params']
['confirm'].'\',array(),\''.$this->getI18nCatalogue().'\')',$return) ;
                }
        }
    return $return ;

  }


Une fois que l'on a fait cela, il faut dire à l'autoloader de Symfony
de charger la classe qu'on vient de créer plutôt que celle qui est
dans lib/vendor/symfony/lib/generator.

Je n'ai pas trouvé d'autre solution que de créer mon propre
autoloader.

Dans lib/extended/myCoreAutoload.class.php, on place le code suivant :

<?php

require_once dirname(__FILE__).'/../vendor/symfony/lib/autoload/
sfCoreAutoload.class.php';

class myCoreAutoload extends sfCoreAutoload {

        public function __construct() {
                parent::_construct() ;
        }

        static public function register() {
                self::getInstance()->classes['sfmodelgenerator'] = '../../../
extended/sfModelGenerator.class.php' ;
                parent::register() ;
        }

}

Et bien entendu, on modifie les premières lignes de config/
ProjectConfiguration.class.php :

require_once dirname(__FILE__).'/../lib/extended/
myCoreAutoload.class.php';
myCoreAutoload::register();

Et après un vidage du cache, Ô miracle, notre message de confirmation
est traduit.

La seule contrainte qu'implique cette solution est de devoir mettre à
jour lib/extended/sfModelGenerator.class.php à chaque nouvelle version
de Symfony. On devrait s'en sortir...

@+

NicoD.

On 26 mai, 14:33, "NicoD." <nicolas.degu...@gmail.com> wrote:
> Bonjour,
>
> @bedomon > Merci pour ta réponse.
>
> Oui, j'ai bien étudié l'internationalisation avant de poster mon
> message.
>
> Tout ce que j'ai développé dans le projet sur lequel je bosse l'est
> faite sur une base d'anglais avec traduction automatique en français
> via les méthodes d'I18n de Symfony. Le couple "Are you sure?"/"Êtes-
> vous sûr(e)" est d'ailleurs présent dans mes fichiers de traductions
> XML. Il permet ainsi de traduire l'alerte de confirmation
> correspondant à la fonction "delete" de Symfony.
>
> Là, je suis vraiment sur un point particulier des mécanismes de
> traduction. Quand je regarde le code actuel de Symfony, je constate
> que via l'admin generator, les messages de confirmation passe à la
> trappe de l'internationalisation pour des actions non standard
> (différent de _edit et de _delete).
>
> Je continue donc ma recherche d'une solution élégante, ayant bien
> l'intention de ne pas déranger la Core Team. ;-)
>
> @+
>
> NicoD.
>
> On 21 mai, 17:11, bedomon <leray.a...@gmail.com> wrote:
>
> > As tu regardé du coté de l'i18n (internationalisation)???
>
> >http://www.symfony-project.org/book/1_0/13-I18n-and-L10n
>
> > Symfony ne possède pas de dictionnaire français anglais par contre tu
> > peux en créer un pour tous les mots à traduire sans aucune ligne de
> > code (juste une ligne de commande)
>
> > Dans le principe la méthode est la suivante (dans les grandes lignes
> > je te laisse la doc pour des compléments)
>
> > Tu crée dans apps/backend/i18n/src_fr/fichier.txt un fichier texte (en
> > UTF-8)
> > dedans tu mets:
> > Are you sur ?#Etes vous sur ?
> > tu enregistres et tu execute la commande propel ou doctrine qui permet
> > de générer le fichier xliff (désolé je ne me rappel plus de la
> > commande).
> > Le fichier xliff générer est un xml.
> > Vérifie au passage que ta 'default_culture' est bien fr_FR dans ton
> > i18n.yml
> > et hop avec cette methode tu ne touche pas au templates mais que aux
> > fichiers de config de symfony
>
> > L'internationalisation fonctionne très bien, je pense que tu va un
> > peux loin en voulant soumettre une évol à la Core Team...
>
> > On 21 mai, 14:30, "NicoD." <nicolas.degu...@gmail.com> wrote:
>
> > > Bonjour à tous,
>
> > > Je cherche une solution "élégante" à mon problème et j'avoue que je
> > > cale un peu.
>
> > > C'est une base de données de livres et j'utilise l'admin generator
> > > pour le gérer. Dans ma liste de livres, j'ai les actions "Modifier" et
> > > "Supprimer". Je cherche à ajouter une fonction "Dupliquer" pour cloner
> > > un enregistrement. Tout se passe bien jusqu'à ce que je souhaite
> > > ajouter une confirmation à cette action pour réduire les manipulations
> > > hasardeuses de l'opérateur.
>
> > > Dans generator.yml, j'ai donc :
>
> > >       list:
> > >         display:        [=titre]
> > >         object_actions:
> > >           _edit:        ~
> > >           _delete:      ~
> > >           duplicate:
> > >             params:
> > >               confirm:  Are you sure?
>
> > > Or le "Are you sure?" n'est pas traduit en français contrairement à
> > > celui du Delete.
>
> > > En explorant le code, je m'aperçois que sfModelGenerator est appelé
> > > pour générer le code HTML de l'action dans le template :
>
> > >   public function getLinkToAction($actionName, $params, $pk_link =
> > > false)
> > >   {
> > >     $action = isset($params['action']) ? $params['action'] :
> > > 'List'.sfInflector::camelize($actionName);
>
> > >     $url_params = $pk_link ? '?'.$this->getPrimaryKeyUrlParams() :
> > > '\'';
>
> > >     return '[?php echo link_to(__(\''.$params['label'].'\', array(),
> > > \''.$this->getI18nCatalogue().'\'), \''.$this->getModuleName().'/'.
> > > $action.$url_params.', '.$this->asPhp($params['params']).') ?]';
> > >   }
>
> > > Et c'est là qu'on remarque que les params de l'action ne sont pas
> > > soumet à la fonction __() contrairement au texte de l'action.
>
> > > Parmi les solutions possible :
> > >  >>> Surcharger le template concerné >>> Simple mais je souhaiterais
> > > éviter pour garder le plus de choses possibles dans config.yml.
> > >  >>> Modifier symfony >>> Possible, mais je souhaite rester dans les
> > > standard et ne pas modifier quelque chose qui est dans un répertoire
> > > vendor
> > >  >>> Proposer la modification de getLinkToAction à la Core Team >>>
> > > Est-ce vraiment important de les déranger pour cela ?
>
> > > Si quelqu'un à un avis, je suis preneur... ;-)
>
> > > Merci.
>
> > > @+
>
> > > NicoD.
>
> > > --
> > > Vous recevez ce message, car vous êtes abonné au groupe Google 
> > > Groupes Symfony-fr.
> > > Pour envoyer un message à ce groupe, adressez un e-mail 
> > > à symfony...@googlegroups.com.
> > > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse 
> > > symfony-fr+unsubscr...@googlegroups.com.
> > > Pour plus d'options, consultez la page de ce 
> > > groupe :http://groups.google.com/group/symfony-fr?hl=fr
>
> > --
> > Vous recevez ce message, car vous êtes abonné au groupe Google 
> > Groupes Symfony-fr.
> > Pour envoyer un message à ce groupe, adressez un e-mail 
> > à symfony...@googlegroups.com.
> > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse 
> > symfony-fr+unsubscr...@googlegroups.com.
> > Pour plus d'options, consultez la page de ce 
> > groupe :http://groups.google.com/group/symfony-fr?hl=fr

-- 
Vous recevez ce message, car vous êtes abonné au groupe Google 
Groupes Symfony-fr.
Pour envoyer un message à ce groupe, adressez un e-mail 
à symfony...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse 
symfony-fr+unsubscr...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : 
http://groups.google.com/group/symfony-fr?hl=fr

Répondre à