Forced to end translation keys with "_html" to get html safe for translations, a good idea?

[rasmusrn]

This recent patch
https://rails.lighthouseapp.com/projects/8994/tickets/4362-patch-make-translate-less-safe-and-more-convenient
changes t() so that translations are no longer html safe unless their
keys ends with ".html" or "_html".

The reasoning is: "translations that do not contain html should not be
marked html safe".

This makes sense - but what about a situation like this:

# we have this translation: en.welcome_message = 'Hello %{user}'
t 'welcome_message', :user => link_to(user.name, user)

Here the translation itself contains no html, but the developer are
still required to name it welcome_html to make it work.

In this context, the reasoning mentioned above does not make sense
anymore.


Should I just add "_html" to translations that I assume I might use
for interpolation, or am I solving the problem (of showing "Hello
[user_link])" the wrong way? Or should t() be changed to accommodate
this problem?

[Michael Koziarski]

> Here the translation itself contains no html, but the developer are
> still required to name it welcome_html to make it work.
>
> In this context, the reasoning mentioned above does not make sense
> anymore.
>
>
> Should I just add "_html" to translations that I assume I might use
> for interpolation, or am I solving the problem (of showing "Hello
> [user_link])" the wrong way? Or should t() be changed to accommodate
> this problem?

You could also wrap your translate call in raw:

raw(t('welcome_message', :user => link_to(user.name, user)))

I don't think there's a nicer fix to this without making the i18n stuff
deeply aware of the xss escaping. Calling raw or using _html in the key
name seems like a reasonable solution.

--
Cheers,

Koz