0

モデル属性に翻訳されたコンテンツを保持するための小さなライブラリを作成しました。以下をモデルに追加するだけです。

class Page < ActiveRecord::Base
  i18n_attributes :title, :content
end

慣例により、データは実際の属性 i18n_title および i18n_content にハッシュ (または Postgres の hstore ハッシュ) として書き込まれます。また、多くのゲッターとセッターを使用すると、「ローカライズされた仮想属性」にアクセスできます。

page = Page.new
page.title_en = 'Hello'
page.title_es = 'Hola'
page.i18n_title   # => { en: "Hello", es: "Hola" }
I18n.locale = :es
page.title        # => "Hola"
page.title_en     # => "Hello"

これらの仮想属性はフォームでも使用できますが、欠点があります。フォーム ビルダーは I18n を使用してラベルを取得し、属性の検証エラーを変換します。もちろん、フォームでactiverecord.attributes.page.title_en使用する場合などのキーを探します。title_en

locales/en.ymletc ファイル内の available_locale ごとに同じ翻訳を複製するのは非常に面倒です。

activerecord:
  attributes:
    page:
      title_en: "Title"
      title_es: "Title"
      ...

私がやりたいことは、Rails がブート プロセスですべてのロケールをロードした後にいくつかのコードを実行し、これらのキーの翻訳を複製することです。これを行う方法はありますか？翻訳が YAML ファイルからロードされた後に呼び出されるフックでしょうか? (私のライブラリがロードされるとき、翻訳はまだロードされていません。)

または、この問題に取り組む別の方法を考えていますか? (私は I18n.translate のエイリアスを作成しようとしましたが、これが将来大きな頭痛の種になるのではないかと心配しています。)

ヒントをありがとう！

4

1 に答える 1

3

このアプローチをやめましたが、私の考えを共有させてください。

特定のローカリゼーションのために、他のロケール文字列を翻訳ファイルに追加することが非常に役立つとは思いません。aconfig/locales/$locale.ymlは通常 (少なくとも私の場合) で始まるので、

$locale:
  ...

activerecord.attributes.page.title_es英語のローカライズ ファイルでは必要ありません。es.ymlのように入れactiverecord.attributes.page.titleます。

つまり、それが個別のローカライズ ファイルの目的ではないでしょうか。(または、開発者/翻訳者の観点から: どのファイルで 、 、またはその両方を検索する必要があります.title_esかen.yml? es.yml)

于 2012-09-28T15:05:33.063 に答える