Oui Etienne, je suis d'accord, la plupart du temps, le format de sortie est du html... Pour ma part, le format de sortie est aussi souvent du json que du html.
Effectivement, _html est le seul raccourci possible mais si tu as une appli qui sert toutes les actions en json et en html, tu vas avoir toutes tes trads en double, c'est vraiment dommage. Les mecs de rails ont ajouté ce helper mais je pense que c'est pas une bonne chose, ca rompt le principe de séparation des responsabilités. C'est à ta vue et uniquement ta vue (les helpers en font partie pour moi) de gérer la présentation, pas aux trads. C'est pas forcément pratique si tu veux un texte avec un peu de présentation (gras, italique ...) mais dans ce cas la, je préfère switcher sur les vues localisées, c'est plus clean. Mon histoire de format de sortie, c'est de ne pas appeler html_safe dans les controller, puisqu'il peut ne pas rendre du html. En général, html_safe est rarement appelée sur autre chose qu'une string qui contient du html. Or, les méthodes qui génèrent du html sont normalement placées dans des helpers, pas dans des controllers. Donc, tu ne devrais jamais trouver un appel a html_safe dans un controller. Voila =) Le 7 février 2012 11:42, Samuel Laulhau <[email protected]> a écrit : > -_- oui c'est effectivement firebug... enfin maintenant firefox à son > propre outil pour inspecter les pages et il ne traduit pas ce genre de > caractère > > Pour le reste, je ne pense pas qu'un fichier de langue doive contenir des > balises html, parce que d'abord on ne demande pas à un traducteur de faire > du html et ensuite car je pense que la plus part du temps s'il y a besoin > d'insérer des balises html dans une chaine de caractères alors cette chaîne > devrait être redécoupée en entités plus petites. > A vrai dire je ne vois pas vraiment dans quel cas c'est avantageux d'avoir > du html dans un fichier de langue, à part si on doit sortir quelque chose > très vite et qui n'évoluera jamais... > > > Le 7 février 2012 11:08, Étienne Barrié <[email protected]> a > écrit : > > Au passage, l’escaping ignore les ®™© dont vous parlez, c’est Firebug >> qui présente les entités sous cette forme au lieu de montrer la >> version utf-8 même si c’est bien elle qui est envoyée. Un view-source >> ou un curl pourra vous en convaincre, ou bien en utilisant >> l’inspecteur de WebKit qui lui n’a pas ce comportement. >> >> Florian, je comprends pas ton histoire de plusieurs formats de sortie, >> ton format de sortie c’est ton contrôleur qui le choisit et ça donne >> une vue. Il se trouve qu’assez souvent c’est du HTML quand même. Et >> parfois dans tes libellés dans ta vue HTML tu veux mettre un peu de >> markup. Et dans ces cas là, au lieu de rajouter html_safe, tu peux >> aussi nommer ta clé _html. Il y a pas 50 formats gérés, html c’est le >> seul raccourci possible. >> >> https://github.com/rails/rails/blob/master/actionpack/lib/action_view/helpers/translation_helper.rb#L83-84 >> Si tu te sers de ta traduction autre part, dans un email plaintext, >> alors tu te sers pas de ce raccourci et tu nommes pas ta clé en _html, >> mais sinon c’est bien pratique. >> >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >> de Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >> [email protected] >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> [email protected] >> > > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
