Rails で en yaml ファイルの作成を開始しました。このファイルを整理しておく規則はありますか?
これまでのところ、私はこの構造を持っています:
language:
resource:
pages: # index, show, new, edit
page html elements: # h1, title
activerecord:
attributes:
model:
property:
今、私はこの構造に適合させたい次のことを持っていますが、方法がわかりません:
t(".update button")) またはt(".update_button")ロケール ファイル構造に規則はありますか?
全体的な最善の戦略は、ファイル構造をある程度再現して、翻訳が与えられたときに、それがどこから呼び出されたのかをすぐに見つけられるようにすることであることがわかりました。これにより、翻訳を行うための何らかのコンテキストが得られます。
アプリケーションの翻訳の大部分はビューにあるため、通常、私の最大の最上位の名前空間はviews.
コントローラー名とアクション名または部分的に使用される ex のサブ名前空間を作成します。
views.users.index.titleviews.articles._sidebar.headerこれらの例はどちらも、翻訳しているアプリの部分と、それを見つけるためにどのファイルを調べる必要があるかを明確にする必要があります。
views.applicationナビゲーションとボタンについて言及しましたが、それらが一般的である場合、それらは対応するビューと同じように名前空間に属します:
views.application._main_nav.links.about_us- アプリのメイン ナビゲーション部分のリンクviews.application.buttons.saveviews.application.buttons.create- 必要なときにすぐに使えるボタンがたくさんありますFlash メッセージはコントローラーから生成されるため、最上位の名前空間は... controllers! :)
ビューに行うのと同じロジックを適用します。
controllers.users.create.flash.success|alert|notice繰り返しますが、「操作が成功しました」などの一般的なフラッシュ メッセージを提供する場合は、次のように記述します。
controllers.application.create.flash.notice最後に、キーは有効な YAML であれば何でもかまいませんが、慣例として単語間の.区切り記号とアンダースコアとしてピリオドを使用することに固執してください。_
今整理しなければならない唯一のことは、レールの翻訳を独自の名前空間に取得して、トップレベルをクリーンアップすることです:)
回答がすでに受け入れられていることは知っていますが、この質問は私に考える材料を与えてくれました。Rails i18n yml ファイルの別の構造を共有して検討/批判できるようにしようと思いました。
私がしたいことを考えると
t('.some_translation')デフォルトのアプリ構造を維持して、ビューのように省略形の「遅延」ルックアップを使用できるようにします。次のようなconfig/locales/en.ymlファイルの場合:
activerecord:
attributes:
user:
email: Email
name: Name
password: Password
password_confirmation: Confirmation
models:
user: User
users:
fields:
email: Email
name: Name
password: Password
confirmation: Confirmation
sessions:
new:
email: Email
password: Password
かなりの繰り返しがあり、「電子メール」や「パスワード」などの単語の文脈は明確であり、それぞれのビューで同じ意味を持っていることがわかります。"Email" を "email" に変更する場合、それらすべてを変更しなければならないのは少し面倒なので、何らかの辞書を参照するように文字列をリファクタリングしたいと思います。&では、次のようなアンカーを使用してファイルの先頭に辞書ハッシュを追加するのはどうでしょうか。
dictionary:
email: &email Email
name: &name Name
password: &password Password
confirmation: &confirmation Confirmation
activerecord:
attributes:
user:
email: *email
name: *name
password: *password
password_confirmation: *confirmation
models:
user: User
users:
fields:
email: *email
name: *name
password: *password
confirmation: *confirmation
sessions:
new:
email: *email
password: *password
ビューでまったく同じ単語/フレーズの複数のインスタンスを取得するたびに、辞書にリファクタリングできます。ベース言語のキーの辞書翻訳がターゲット言語にとって意味をなさない場合は、ターゲット言語の参照値を静的文字列に変更するか、ターゲット言語の辞書に追加のエントリとして追加します。各言語の辞書が大きくなりすぎて扱いにくい場合は、別のファイルにリファクタリングできると確信しています。
i18n yaml ファイルを構造化するこの方法は、私が試したいくつかのローカル テスト アプリでうまく機能するように見えました。すばらしいLocaleappが将来、この種のアンカー/参照をサポートしてくれることを願っています。とにかく、この辞書の話はすべてオリジナルのアイデアである可能性はありません.YAMLでのアンカー参照、または一般的な「辞書」の概念全体に他の問題がありますか? それとも、デフォルトのバックエンドを完全に取り除いて、Redisなどに置き換えるほうがよいのでしょうか?
あなたの質問に答えるのは簡単ではなく、そのトピックに関する資料はあまりありません。最高のリソースは次のとおりです。
だから私はそれをここで直接試してみます：
ナビゲーション
ここでは、ブレッドクラム、タブなどのナビゲーション要素を意味していると思います...それらのビューを定義し、すべてのビュー要素をディレクトリ内の個別のファイルに移動するというviews規則に従う必要があります (規則についてはスタイルガイドを参照してください)。
ボタンのテキスト (変更の保存、アカウントの作成など)
要素を表示し、同じファイルにも移動します。異なるビューで同じボタンを使用する場合は、共通ファイルを定義してから使用してください。
コントローラ フラッシュからのエラー メッセージ
ビューと同じルールを使用します。別のディレクトリを定義し、そこにコントローラのファイルを含めます。
複数単語キーを追加する方法。スペースまたはアンダースコアを使用しますか? たとえば、t(".update ボタン")) または t(".update_button")
これが 1 つのキーであることをより明確にするため、私は個人的には.update_buttonではなくを使用することを好みます。.update button
yaml ファイルを直接編集すると、ファイルが乱雑で判読不能になります。
さらに、いつの日か、非開発者に新しい言語を追加してもらいたい場合、翻訳者へのアクセスを提供することは困難です。
単一の yaml ファイルを生成するlocaleappを使用することをお勧めします。
ただし、Web インターフェイスで翻訳を簡単に表示および管理できます。
そして、翻訳者への追加アクセスを作成します。