どのフィールドにどの検証エラーが追加されたのかを、「表示言語やエラーメッセージに依存しない形で」テストする方法 - Qiitaはじめに Railsアプリケーションでモデルのバリデーションを検証するをテストケースを想定します。 たとえば、「姓が空文字列であれば検証エラーが発生すること」をテストしようとすると、次のようなテストが書けます。 john = User.new(first_name: '', last_name: 'Lennon') john.valid? expect(john.errors[:first_name]).to include("can't be blank")
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
MessageFormat
Pluralization for JavaScriptという名詞の複数形についての記事を読んで、MessageFormatという仕組みがあることを初めて知った。複数形や三単現、性別による言葉遣いの違いなどを言語ごとに定義しておき、出力する際にその定義を利用して自然な結果になるようにする仕組みのようだ。 MessageFormatの仕組み自体もわかりやすくて良かったが、記事に書かれているようにちょっとしたローカライズにおいても威力を発揮しそうなのが良さそうに思えた。昨今のウェブサイトやウェブアプリにおいては、完全な国際化やローカライズよりも重要なUIパーツの正確なローカライズがまず必要になっているので、そういう小さなところから使える仕組みであるMessageFormatはポイントが高いだろう。国際化はともかく、完全なローカライズくらいまではスケールすると思えるので、規模によっては使えないと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
