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 &reg;, 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>" %> #=> &lt;a&gt;

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>" %> #=> &lt;a&gt;
<%= "<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 &reg; 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]

Répondre à