このStackOverflowの質問は、Rails i18nファイルの適切な構造について考えるための材料を与えてくれたので、検討/批評のためにRailsi18nymlファイルをリファクタリングするための別の構造を共有したいと思いました。
私がしたいことを考えると
- デフォルトのアプリ構造を維持して、ビューのよう
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
かなりの繰り返しがあり、「Eメール」や「パスワード」などの単語の文脈は明確であり、それぞれの見方で同じ意味を持っていることがわかります。「Email」を「e-mail」に変更することにした場合、すべてを変更しなければならないのは少し面倒なので、ある種の辞書を参照するように文字列をリファクタリングしたいと思います。&したがって、次のようなアンカーを使用して、ファイルの先頭に辞書ハッシュを追加するのはどうでしょうか。
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でのアンカー参照に他の問題があるのでしょうか、それとも一般的な「辞書」の概念全体に問題があるのでしょうか。または、Railsのデフォルトのi18n規則を超える必要がある場合は、デフォルトのバックエンドを完全に取り除いてRedisなどに置き換える方がよいでしょうか。
編集：
私は、彼の回答の下にある別のコメントとしてではなく、ここにある下のコメントに記載されているtigrishのワークフローの例に取り組みたいと思いました。ポイントが得られていないように思われる場合、または私が単純な場合は、失礼します。
ポイント1：ActiveRecordモデルの一般的な「名前」属性があり、それらはすべて名前の汎用ディクショナリを指しているだけです。
dictionary:
name: &name Name
activerecord:
attributes:
name: *name
user:
name: *name
product:
name: *name
ポイント2：ユーザーモデルの名前のみを変更する必要があります。他の名前は同じままです。
オプション1：モデルフィールド名をバックエンドで同じに保ち、それが指すフロントエンドの変換を変更するだけです。
dictionary:
name: &name Name
full_name: &full_name Full Name
activerecord:
attributes:
name: *name
user:
name: *full_name
product:
name: *name
オプション2：ユーザーモデルのフィールド名も変更します。これには、コード内のこのキーへの参照を変更し、change_table/rename_column移行する必要があります。
dictionary:
name: &name Name
full_name: &full_name Full Name
activerecord:
attributes:
name: *name
user:
full_name: *full_name
product:
name: *name
オプション3：非常に徹底したい場合は、「名前」に含まれる情報をリファクタリングして、データベース/ Activemodelフィールドを分離します。これには、新しい辞書エントリと移行が必要になります。「フルネーム」をどのように表示するかをビューで決定できます。
dictionary:
name: &name Name
name_prefix: &name_prefix Prefix
first_name: &first_name First
middle_name: &middle_name Middle
last_name: &last_name Last
name_suffix: &name_suffix Suffix
activerecord:
attributes:
name: *name
user:
name_prefix: *name_prefix
first_name: *first_name
middle_name: *middle_name
last_name: *last_name
name_suffix: *name_suffix
product:
name: *name
ポイント3：何らかの理由で翻訳を変更する必要があります。この場合はマーケティングです。ポイント2オプション1の例から続けます
オプション1：モデルフィールド名は同じです。フロントエンドの変換を変更するだけです。
dictionary:
name: &name Name
full_name: &full_name Full Name
funky_name: &funky_name Ur Phunky Phresh Naym
activerecord:
attributes:
name: *name
user:
name: *full_name
product:
name: *name
sessions: # Sign up page keys
new:
name: *funky_name
オプション2：何らかの理由で、「ファンキーな名前」もデータベースに保存する必要があります。username誰も反対しない場合（またはfunky_name何らかの理由でマーケティングが主張する場合）、それをaと呼びましょう。
dictionary:
name: &name Name
full_name: &full_name Full Name
funky_name: &funky_name Ur Phunky Phresh Naym
activerecord:
attributes:
name: *name
user:
name: *full_name
username: *funky_name
product:
name: *name
sessions: # Sign up page keys
new:
name: *name
funky_name: *funky_name
そうです、私は自分が何をしているのかほとんどわからないことを認めますが、Hamlでi18nを操作するこの方法がRailsアプリで悪い考えである理由を理解するために、公に撃墜されるつもりです。読みにくい？メンテナンスの悪夢？言語の機能（私が思うに）を使用する場合、それは本当に「ファイル形式のハッキング」と見なされますか？
このすべてを取り除くために私を駆り立ててくれたtigrishにもう一度感謝します。