1

私は顧客が製品を作成するアプリケーション（eコマースWebサイトなど）を作成しているので、明らかにデータベースに保存された翻訳された説明が必要です。顧客にgit/ymlの学習を強制することはできません。

説明（そして最終的には製品名）を正しくローカライズしてデータベースに保存する方法について2つのアイデアがありますが、使用すべきよく知られたアプローチがあれば、それを知って本当にうれしく思います。

最初のアイデアは私にとって最も論理的だと思いますが、私にはそれを「透明」にしたいのです。どこにでも結合を書きたくないので、これを達成する方法についての提案が正しい場合は、感謝。

アイデア1： データベーステーブルを作成し（productsフィールドはデフォルトのロケール言語に設定されている可能性があります）、次のように構造化されたテーブルを含むテーブルを作成します。namedescriptionproducts_translations

products_translations
- id
- locale
- product_id
- name
- description

例として：product_translation: { id: 1, locale: 'en', product_id: 3, name: 'toy', description: 'play' }

しかし、私はどこにでもたくさんのIFを書く必要なしに翻訳にアクセスしたいと思っています。したがって、product.nameと書くと、現在のロケールに基づいてenまたはitが返されます。

ボーナス：これを達成するのに役立つ宝石はありますか？

アイデア2：もう1つのアイデアは、などを含むテーブルをname_locale1作成name_itすることですが、モデルオブジェクトをフィールドで汚染し、巨大なテーブルを作成するため、このアプローチは好きではありません。

ただし、このようにして、そのオブジェクトのすべてのクエリで結合を回避できます。

私が知らないより大きなアプローチ（データベースパターンなど）がある場合は、それも問題ありません。これら2つのアイデアだけに厳密にする必要はありませんが、2つから選択する必要があります。どちらが良いかわからない。

重要：データベースでの翻訳が明らかに必要な動的コンテンツを除いて、翻訳をymlファイルに保存したいと思います。

4

2 に答える 2

3

私はPinnyMに同意しますが、最初のアプローチの方が2つのうち優れていますが、独自のスキーマを実装するのではなく、構造上の決定のほとんどが行われるGlobalize3を実装することを強くお勧めします（そしてFuchs氏自身も同様です）。 ）。また、railsヘルパーを使用するとproduct.name、モデルインスタンスのようなものを呼び出すだけで、gemはそれを正しいロケールで表示する方法を理解します。

于 2013-01-27T21:47:04.517 に答える
2

最初のアプローチが推奨されます。あなたが推測したように、2番目のアプローチはそれほどクリーンではなく、このモンスターテーブルに参加する必要があるため、コーディング側でより多くの作業が必要であり、実際の利益はありません。逆に、最初の方法では最大で1つの結合が必要ですが、2番目の方法では、ローカリゼーションサポートを追加する可能性のある各属性での結合が必要です。

次のようなすべての製品呼び出しにスコープを追加するだけです。

scope :for_locale, lambda{|locale| joins(:product_translations).
                                   where(product_translations: {locale: locale || 'en'}) }

セッションロケール（または保存している場所）を渡します。

于 2013-01-27T20:34:17.623 に答える