I18n.tでHTMLを出力するのにrawやhtml_safeを使ってはいけない - Qiita
みたいなのを書くわけですが、このままだと html_safe でないので自動的にエスケープされてしまいます。 <strong>tnj</strong>さんからメッセージがあります！ 悲しい！ 正しい HTML の含み方 この問題に直面した Rails I18n 初級者は、「じゃーエスケープ避けてそのまま出力させるしかなくない？」と、 raw だったり html_safe を付けてしまいがちです。 でもそうなると、もし @username にタグが含まれていた場合もエスケープされずに出力されてしまうので、簡単に XSS を引き起こしてしまいます。「ここはユーザー入力値は入らないから大丈夫だよ！」は絶対守り切れないし、変数を必要とするたびに「本当にユーザー入力値入ってこないんだっけ?」なんて判断をいちいち必要としていては時間がいくらあっても足りないので、機械に任せたいところです。 で、 Rai
Ruby on RailsのI18nで使用する名前空間に関してのまとめと、ベストプラクティスの検討。 - 波打際のブログさん
はじめに Ruby on RailsにはI18nというgemが標準で同梱されており、特に何もせずとも文章の国際化を行うことができる仕組みになっています。ちなみに、I18nとはinternationalizationを表しており、iとnの間に18文字あるから `I18n` だそうです。 最近関わっているRailsのプロジェクトで国際化を行うタスクが発生し、I18nの辞書ファイルを定義する際に、定義ファイル中の名前空間(ロケール情報を定義する場所)について、どのような構造で配置するべきか調べる機会があったのでまとめておきます。 2013年12月14日 Rubyの徳が高い同僚が、グローバルなattributesに関しての情報を見つけてくれたので追記しました。 2014年07月04日 ロケールファイルの構成を一部見直しました。 環境 Rails4 想定環境 rails generateで name
RailsのI18n APIの使い方の基本と辞書ファイルの整理方針: Modelごと、Viewごとに分けて管理する - memo.yomukaku.net
Railsではi18nのAPIが使用できます。 I18n APIって何でしょうか？ 何ができるのでしょうか？ 荒っぽく書けば、helloというキーが指定された時に、対象言語が英語の場合は「Hello」、日本語の場合には「こんにちは」と出力できるような辞書ファイルを作成し、それを使用することを意味します。 「英語なんか使わない。自分のサイトは日本人しか来ない」という場合でもI18n APIの使用が便利なため、しばしば使われます。 例えば、数人でRailsアプリを開発する場合に、Userモデルの登録のためのビューを作成していたとしましょう。 ある人は、User#emailのラベルを次のように「Eメール」と書きます。 <label for="user_email">Eメール</label> ところが、別の開発者は別の場所で次のように「E-Mail」と書いたりします。 <label for="us
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
