Railsで日本語サービスを作るときのテンプレート - Qiita
config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}').to_s] config.i18n.default_locale = :ja config.i18n.available_locales = [:ja, :en] config.time_zone = 'Tokyo' ja: activerecord: errors: template: header: one: "%{model}にエラーが発生しました。" other: "%{model}に%{count}つのエラーが発生しました。" body: "次の項目を確認してください。" messages: taken: "はすでに存在します。" record_invalid: "バリデーションに失敗しました。 %{error
国際化に対応したDB設計で一般的に用いられる方法と、メリット・デメリットを教えて下さい。…
国際化に対応したDB設計で一般的に用いられる方法と、メリット・デメリットを教えて下さい。 ＠単純にフィールドを増やす： contents (table) -id -comment_jpn -comment_usa -comment_fra -author .. ＠テーブル単位で増やす： contents_jpn (table) -id -comment -author .. contents_usa (table) -id -comment -author .. ＠マスター言語以外をまとめる： contents (table) : master扱い -id -comment -author .. contents_i18n (table) -id -content_id : fk -locale : usa,fra.. -comment .. ＠全言語を並列に： contents (tab
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
i18nについて | 酒と涙とRubyとRailsと
