Merci por vos réponses, effectivement j'ai peut-être perdu un peu de temps et était insistant :)
Bonne journée. et merci encore pour vos éclaircissement Le 7 février 2012 00:34, Florian Dutey <[email protected]> a écrit : > J'en profite pour ajouter que le marquage html_safe ne doit pas être fait > dans le controller (puisqu'il peut rendre autre chose que du html) mais > dans la vue ou dans un helper =) > > Le 7 février 2012 00:33, Florian Dutey <[email protected]> a écrit : > > Je pense que c'est fait automatiquement parce que tu est dans une vue html >> et que ta string n'est pas "html_safe". >> >> Ce n'est pas t() qui transforme ton ® en ®, c'est <%=. >> >> En rails 2, aucune string n'était échappée par défaut et il fallait le >> faire manuellement avec la method h: >> >> <%= "<a>" %> #=> <a> >> <%=h "<a>" %> #=> <a> >> >> En rails 3 c'est l'inverse. Les string sont marquées comme non "html >> safe" par défaut et sont échappées automatiquement quand elles sont >> affichées à l'aide de <%=. >> Pour éviter ce comportement, il faut les marquer comme étant safe >> >> <%= "<a>" %> #=> <a> >> <%= "<a>".html_safe %> #=> <a> >> >> Ce comportement permet d'éviter les injections de html et de javascript. >> Il permet aussi d'éviter les problèmes d'affichage si ta page n'a pas de >> charset ou que celui-ci n'est pas de l'utf-8. >> Transformer les \n en <br /> ne relève pas de l'escaping. Si tu veux >> afficher ta string dans un <pre>, tu ne DOIS PAS transformer tes sauts de >> ligne en <br /> par exemple. En fait, ce replacement n'est utilisé que pour >> les zones de texte, qui sont rares en comparaison des champs textes >> simples. C'est pour ça que cette transformation est laissée à la discrétion >> du développeur, vu que ce n'est pas le comportement le plus courant. >> >> Après moi ce que j'en dis, c'est très bien de chercher à comprendre le >> pourquoi du comment du but, mais le temps que t'es en train d'y passer est >> largement supérieur à celui nécessaire pour utiliser un simple_format >> t('key') =). >> >> J'espère en tout cas que toutes ces explications t'aident. >> >> Le 6 février 2012 18:27, Samuel Laulhau <[email protected]> a écrit : >> >> ok, mais comment vous expliqué que ® est converti en ® sans que je >>> ne demande rien et pas les sauts de ligne. >>> Est ce que ce ne serait pas plus intelligent de pousser ça au bout et de >>> convertir ces caractères aussi, pour que le rendu html soit le plus proche >>> de la chaîne d'entrée ? >>> >>> >>> >>> >>> >>> Le 6 février 2012 17:40, Florian Dutey <[email protected]> a écrit : >>> >>> Mouais, le fait de mettre des clefs '*_html', c'est un peu naze. Imagine >>>> que t'as 50 formats de sortie, tu dois faire 50 clefs différentes pour le >>>> meme mot? >>>> >>>> C'est à la vue de gérer la facon dont on rend le texte. La traduction >>>> c'est juste un gros dico et ca doit être indépendant du reste. >>>> >>>> Pourquoi? >>>> >>>> * si tu veux réutiliser tes trads dans d'autres projets. Tu peux ne pas >>>> utiliser de rendu html et/ou ne plus vouloir les sauts de ligne >>>> * ta vue html converti les sauts de ligne en br, ta vue excel ne >>>> convertit rien, ta vue xml ne converti rien, ta vue pdf ne convertit rien, >>>> ta vue json ne convertit rien... >>>> * admettons que tu mettes de <br> partout dans le yml et que demain tu >>>> veuilles changer pour des <br />, ben t'as beaucoup de boulot pour rien, >>>> difficile à facturer au client en plus (nva) >>>> >>>> En l'occurence, dans ta vue html, tu as juste à faire un banal <%= >>>> simple_format t('clef') %>, c'est pas le bout du monde =) >>>> Autrement, si ce sont des gros textes et qu'ils ne sont liés qu'à la >>>> vue html, tu peux utiliser les vues localisées. >>>> >>>> Par exemple, pour l'url http://url/products/1 >>>> >>>> app/ >>>> views/ >>>> products/ >>>> show.en.html.erb >>>> show.es.html.erb >>>> show.fr.html.erb >>>> >>>> Comme ca t'écrit le texte qu'une fois, en html directement mais dans un >>>> fichier html et c'est réglé =). >>>> >>>> >>>> Le 6 février 2012 16:14, Étienne Barrié <[email protected]> a >>>> écrit : >>>> >>>> Sinon, tu considères que tes traductions peuvent contenir du HTML, tu >>>>> nommes les clés en finissant par un _html et t’auras pas besoin >>>>> d’anticiper côté template, mais tu devras quand même coder les <br> à >>>>> la main dans le YAML. >>>>> >>>>> En même temps le framework est pas magique, il va pas te transformer >>>>> tes traductions sans te demander ton avis (sauf pour des questions de >>>>> sécurité, il va échapper le html si la clé ne se finit pas par _html). >>>>> >>>>> On Mon, Feb 6, 2012 at 16:00, Samuel Laulhau <[email protected]> >>>>> wrote: >>>>> > Bonjour, >>>>> > dans ce cas je dois dans mon template anticiper toutes les chaines >>>>> qui >>>>> > pourraient contenir des retours à la ligne ? >>>>> > J'avais trouvé cet helper plus tôt en cherchant une réponse à mon >>>>> problème >>>>> > je trouve cette solution assez décevante. En core une fois je pense >>>>> que le >>>>> > framework est assez bien fait pour savoir que quand la sortie est du >>>>> html >>>>> > certains caractères doivent être traduits alors pourquoi pas cela ? >>>>> > >>>>> > >>>>> > >>>>> > Le 6 février 2012 14:10, Alexandre Friquet <[email protected]> a >>>>> écrit : >>>>> > >>>>> >> Bonjour, >>>>> >> >>>>> >> Le 6 février 2012 13:54, sam <[email protected]> a écrit : >>>>> >>> >>>>> >>> Du coup je me demande pourquoi les retours à la ligne ne sont pas >>>>> >>> convertis eux aussi ? Et comment les convertir ? Ajouter les >>>>> balises br dans >>>>> >>> les fichiers de langue ? convertir les sauts à la ligne en br dans >>>>> les >>>>> >>> templates ? >>>>> >> >>>>> >> >>>>> >> Je pense que simple_format devrait te convenir : >>>>> >> >>>>> >> >>>>> http://api.rubyonrails.org/classes/ActionView/Helpers/TextHelper.html#method-i-simple_format >>>>> >> >>>>> >> -- >>>>> >> Alex >>>>> >> >>>>> >> -- >>>>> >> 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] >>>>> >>>>> >>>>> >>>>> -- >>>>> Étienne Barrié >>>>> >>>>> -- >>>>> 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] >>> >> >> > -- > 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]
