web-dev-qa-db-ja.com

Railsでi18n yamlファイルをどのように構成しますか？

Railsでen yamlファイルを作成し始めましたが、やがて手間がかかり、手に負えなくなることが既にわかります。このファイルを整理する規則はありますか？

これまでのところ、私はこの構造を持っています：

_language:
  resource:
    pages: # index, show, new, edit
      page html elements: # h1, title
  activerecord:
    attributes:
      model:
        property:
_

今、私はこの構造に適合させたい以下のものを持っていますが、どうすればいいのかわかりません：

  1. ナビゲーション
  2. ボタンのテキスト（変更の保存、アカウントの作成など）
  3. コントローラフラッシュからのエラーメッセージ
  4. マルチワードキーを追加する方法。スペースまたはアンダースコアを使用しますか？たとえば、t(".update button")）またはt(".update_button")の場合

ロケールファイル構造に規則はありますか？

ruby-on-railsruby-on-rails-3internationalizationstructureyaml
51
Mohamad

全体的な最善の戦略は、ファイル構造をいくぶん再現することであるため、翻訳が行われたときにどこから呼び出されたのかをすぐに見つけることができます。これにより、翻訳を行うための何らかのコンテキストが得られます。

アプリケーションの翻訳の大部分はビューに含まれているため、私の最大のトップレベル名前空間は通常viewsです。

Exで使用されているコントローラー名とアクション名または部分的なサブ名前空間を作成します。

  • views.users.index.title
  • views.articles._sidebar.header

これらの例はどちらも、アプリのどの部分を翻訳しているのか、それを見つけるためにどのファイルを調べるのかを明らかにするはずです。

ナビゲーションとボタンに言及しますが、それらが汎用である場合は、views.application名前空間は、対応するビューと同じように：

  • views.application._main_nav.links.about_us-アプリのメインナビゲーション部分のリンク
  • views.application.buttons.save
  • views.application.buttons.create-必要なときに使用する準備ができたこれらのボタンがたくさんあります

Flashメッセージはコントローラーから生成されるため、それらの最上位の名前空間は... controllers！です。 :)

ビューと同じロジックを適用します：

  • controllers.users.create.flash.success|alert|notice

繰り返しますが、「Operation successful」などの汎用フラッシュメッセージを提供する場合は、次のように記述します。

  • controllers.application.create.flash.notice

最後に、キーは有効なYAMLであれば何でもかまいませんが、ピリオドの使用に固執してください.区切り文字およびアンダースコアとして_慣習としての単語間。

整理すべき唯一のものは、Railsの翻訳を独自の名前空間に変換して、トップレベルをクリーンアップすることです:)

61
tigrish

答えはすでに受け入れられていることは知っていますが、この質問は私に考えの糧を与えてくれました。あなたの考察/批評のためにRails i18n ymlファイルの別の構造を共有したいと思いました。

私がしたいことを考えると

  1. デフォルトのアプリ構造を保持して、ビューでt('.some_translation')のような簡単な「遅延」ルックアップを使用できるようにします。
  2. 特に同じ単語だけでなく、同じコンテキスト/意味を持つ単語では、文字列の繰り返しをできるだけ避けます。
  3. キーを一度変更するだけで、参照されているすべての場所に反映されます。

次のような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」を「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でのアンカー参照に他の問題があるのでしょうか、それとも一般的な「辞書」概念全体にあるのでしょうか？それとも、単にデフォルトのバックエンドを完全にリッピングし、それを Redis または何かに置き換える方が良いでしょうか？

50
Paul Fioravanti

この質問をしてからほぼ2年が経ちましたが、いくつかの洞察を共有したいと思います。最適な構造は、MVCの役割（モデル、ビュー、コントローラー）に応じて名前空間を変換することです。これにより、ロケールファイルが整頓され、名前空間の競合が防止されます（たとえば、スコープ_en.users_はビューまたはコントローラーを表すことができます）。

_en:
  controllers:
    users:
      show:
        welcome_flash: "Welcome back!"
  mailers:
    users_mailer:
      welcome_email:
        subject: "Good of you to join us"
  views:
    users:
      show:
        notice: "Oh no!
_

しかし、そのような整頓された名前空間を使用すると、Railsの遅延検索機能が壊れます。遅延検索を使用する場合、Railsは自動的に名前空間を挿入し、作成した最上位の名前空間（views、controllers、等...）。

たとえば、t('.welcome_flash')のスコープは_en.users.show_に解決されます。ユーザーが明確に定義されていないため、これは悪臭を放ちます。それは何ですか？コントローラー？ビュー？他に何か？

この問題を解決するために gem I18nLazyLookupを作成しました 。独自のカスタム名前空間で遅延検索を使用できます。

tを使用する代わりに、t_scoped('welcome_flash')を使用できます。これにより、スコープが自動的に_en.controllers.users.show_に解決されます。ビューやメーラーでも機能し、名前空間を好きなようにカスタマイズできます。

8
Mohamad

あなたの質問に答えるのは簡単ではなく、そのトピックに関する資料はあまりありません。最高のリソースは次のとおりです。

  • Rails Styleguide 、セクション国際化
  • I18n wiki には多くのリソースがありますが、あなたの質問に答えるリソースは見つかりませんでした。

ここで直接試してみましょう：

  • ナビゲーション

    ここで、パンくずリスト、タブなどのナビゲーション要素を意味すると思います...それらのビューを定義してから、ルールに固執して、すべてのビュー要素をディレクトリviews（ルールのスタイルガイド）。

  • ボタンのテキスト（変更の保存、アカウントの作成など）

    要素を表示し、同じファイルに移動します。異なるビューで同じボタンを使用する場合は、共通のファイルを定義してから使用します。

  • コントローラフラッシュからのエラーメッセージ

    ビューと同じルールを使用します。別のディレクトリを定義し、そこにコントローラ用のファイルを含めます。

  • マルチワードキーを追加する方法。スペースまたはアンダースコアを使用しますか？たとえば、t（ "。update button"））またはt（ "。update_button"）

    個人的には、.update_buttonではなく.update buttonを使用することを好みます。これは、これが1つのキーであることをより明確にするためです。

8
mliebelt

Yamlファイルを直接編集すると、乱雑で読みにくいファイルになります。
さらに、いつか開発者以外の人が新しい言語を追加したい場合、翻訳者にアクセスを提供するのは難しいでしょう。

localeapp を使用することをお勧めします。これは単一のyamlファイルを生成します。
ただし、ウェブインターフェースで翻訳を簡単に表示および管理できます。
そして翻訳者への追加アクセスを作成します。

6
Damien MATHIEU

戦いの数年後に来ますが、ここに（多少完全に）異なる答えがあります。

そもそも、ファイル構造に基づいたデフォルトの名前空間を持つ標準のt('.xxx')スタイルは好きではありません。また、DOM構造に依存する翻訳の分類もあまり好きではありません。これは非常に構造化された翻訳のための素晴らしいアプローチですが、多くの場合反復的であり、あまり直感的ではありません。

私は翻訳者をより便利なカテゴリに再グループ化し、翻訳者が簡単にできるようにします。なぜなら、彼らは奇妙なスタイルではなく具体的​​なテーマに取り組むことができるからです（一部の翻訳者はMVCの意味さえ知らない）

翻訳ファイルはこのように構成されています

fr:
  theme1:
    theme11:
      translationxxx: blabla
  theme2:
    translationyyy: blabla

ニーズに応じて、「テーマ」は、翻訳者にとって最も直感的なモデル、より抽象的なコンテキストなどになります。

これはビューのスコープを毎回書くのが面倒なので、スタックベースの翻訳コンテキストを持つためにヘルパーに便利なメソッドをいくつか追加しました。

  • t_scope([new_scope]およびpop_tを呼び出して、ビュー内のスタックで翻訳スコープをプッシュ/ポップします
  • tヘルパーをオーバーライドして、スタックの最後のスコープを使用します

翻訳スコープメソッドのコードは その答え で利用可能です

0
Cyril Duchon-Doris