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

rubyonrails-core
1

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?

2

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.