Le répertoire i18n à la racine d'un projet n'est pas pris en compte par symfony. J'avais été surpris de ça il y a quelques mois, il n'est pas possible de mutualiser des traductions pour toutes les applications d'un même projet (à part définir un même et unique sf_app_i18n_dir pour toutes les applications, ce qui ne permet plus alors d'avoir des traductions pour une seule application).
J'avais proposé un simple patch pour symfony 1.2 http://trac.symfony-project.org/attachment/ticket/6339/sfApplicationConfiguration.patch , il est facilement adaptable pour 1.3 / 1.4 (suffit de changer les lignes, cf http://trac.symfony-project.org/browser/branches/1.4/lib/config/sfApplicationConfiguration.class.php ) CD 2009/12/7 Benoît Nadaud <[email protected]> Merci pour les conseils pour le choix des labels, ils sont explicites et non équivoques dans mon cas. Par contre si on met un répertoire i18n à la racine du projet, je ne vois pas pourquoi Symfony irait prendre les traduction dans ce dossier, l'idéal serait que les traductions provenant des classes de formulaires soient effectivement dans un fichier commun aux 2 applications (frontend et backend) donc effectivement à la racine du projet ce serait bien. Mais cela n'enlève rien au fait que l'on ne peut pas utilser i18n:extract pour extraire les labels et messages de d'erreurs de validateur utilisés dans les classes de formulaires. On 6 déc, 22:47, Alexandre Salomé <[email protected]> wrote: > Bonjour, > > Il doit être possible de placer les fichiers dans un dossier i18n à la > racine du projet. A tester, je n'ai jamais essayé. > > Ensuite, il faut que tu définisses dans ton formulaire les labels les plus > parlants (en anglais). Ensuite, faire l'I18N de ces labels. > > Il faut que les traductions soient le plus évident possible. > > J'ai déjà trouvé des applications où on traduisait "answers" en "voir les > réactions", et je peux te garantir que ça pose vite des problèmes... > > Tiens nous au courant si tu essaie le dossier i18n dans le projet. > > Alex' > > Le 6 décembre 2009 17:14, Benoît Nadaud <[email protected]> a écrit : > > > > > > > Bonjour, > > > J'utilise symfony 1.2 et j'ai quelques questions au sujet de > > l'internationalisation des formulaires. > > La tâche i18n:extract n'extrait pas les labels et messages d'erreur > > des validateurs. Comment procédez-vous ? > > > J'ai essayé un hack trouvé à cette adresse > >http://trac.symfony-project.org/ticket/5668 > > mais déconseillé par Fabien Potencier. Cela fonctionne mais je me > > retrouve avec le problème suivant : les chaines faisant appel à la > > fonction __() se retrouve dans chaque fichier XX/messages.xml (XX > > étant la langue) de toutes les applications (mon projet en contient > > 2 : frontend et backend). Ceci pose évidemment des soucis de mise à > > jour, il faut maintenir les 2 fichiers XLIFF à jour en cas de > > changement. > > > Quelqu'un a-t-il une meilleure solution ? > > > Pour l'instant je ne vois que les solutions suivantes : > > - utiliser la méthode classique, à savoir : ne pas utiliser __() > > dans les classes de formulaires et ajouter à la main chaque chaine à > > internationaliser dans le fichier messages.xml. Mais cela implique > > toujours un travail de maintenance fastidieux (nb de fichiers XML à > > maintenir = nb d'applications X nb de langues) > > - ne pas définir les labels dans les classes de formulaires et les > > mettres dans les vues ou dans les fichiers generator.yml selon les > > cas. Mais quid des messages d'erreurs de validateurs ? > > -- > Alexandre Salomé -- [email protected] --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "Symfony-fr" de Google Groupes. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour afficher d'autres options, visitez ce groupe à l'adresse http://groups.google.com/group/symfony-fr?hl=fr -~----------~----~----~----~------~----~------~--~---
signature.asc
Description: OpenPGP digital signature
