5

この質問は他の多くの質問と似 て いるかもしれませんが、i18n、特に FuelPHP の最適なアプローチについて意見/提案を求めたいと思います。

だから、ここに私がこれまでに持っているものがあります：

データベース スキーマ #1:

models (id, name_pt, name_es, name_en, description_pt, description_es, description_en)

サンプルデータ #1:

(1, 'Modelo', 'Modelo', 'Model', 'Descrição do modelo', 'Descripción del modelo', 'Model description')

長所：

  • ストレートでシンプル
  • モデルごとに 1 つのテーブル
  • JOINを使用する必要はありません
  • データアクセスを簡素化するための魔法の方法の使用:

 

public function & __get($property)
{
    if (array_key_exists($property, array('name', 'description')))
    {
        $property = $property.'_'.Session::get('lang_code');
    }

    return parent::__get($property);
}

このようにして、私は電話をかけることができます:

$model->name;
$model->description;

それ以外の：

$model->{'name_'.Session::get('lang_code')};
$model->{'description_'.Session::get('lang_code')};

短所：

  • 多くの言語/翻訳されたフィールドがあると、面倒になる可能性があります。
  • 新しい言語を追加することは、テーブルに新しいフィールドを追加することを意味します
  • 魔法の方法は、ORM インスタンス/オブジェクトが既にある場合にのみ機能します。変換されたフィールドで並べ 替えられたクエリ ビルダーを介して ORM インスタンスを取得するには、次のようなコードが必要です。

 

Model_Model::query()
    ->order_by('name_'.Session::get('lang_code'))
    ->get();

データベース スキーマ #2:

languages (id, code, name)
models (id)
i18n_models (id, model_id, language_id, name, description)

サンプルデータ #2:

-- languages
(1, 'pt', 'Português')
(2, 'es', 'Español')
(3, 'en', 'English')

-- models
(1)

-- i18n_models
(1, 1, 1, 'Modelo', 'Descrição do modelo')
(2, 1, 2, 'Modelo', 'Descripción del modelo')
(3, 1, 3, 'Model', 'Model description')

長所：

  • より良いデータ編成
  • 新しい言語の追加は簡単です
  • 最初のアプローチと同様に、 set()メソッドを使用して $_custom_data 配列にデータを入力することで、直接データにアクセスすることもできます。

 

$i18n = Model_I18n_Model::query()
    ->where('model_id', $model->id)
    ->where('language_id', Session::get('lang_code'))
    ->get_one();

$model->set(array(
    'name' => $i18n->name,
    'description' => $i18n->description
));

短所：

  • 複雑さが増す
  • JOIN または 2 番目のクエリを使用する必要があります
  • モデルごとに追加のテーブルが必要です

データベース スキーマ #3:

他の質問では、モデルが持っている各翻訳の行を使用して、すべての翻訳に中央の i18n テーブルを使用することを提案する人を見てきました。

長所：

  • モデル間で共有される i18n 用の単一テーブル
  • 前のアプローチと同様に、新しい言語の追加は簡単なはずです

短所：

  • データのフェッチ中に複雑さが増し、モデルに含まれるすべての翻訳済みテキストに対して JOIN が必要になります
  • このアプローチでEAV コンテナーを使用することもできますが、これはマッピングにキー/値を使用しますが、この場合は特に、language_id を使用して適切な翻訳をフェッチする必要があります。

個人的には、2 番目のアプローチを好みます。他にどのような利点/欠点がありますか? FuePHP で別の方法で i18n を実装した人はいますか? あなたのアイデアを共有してください:)

4

1 に答える 1

2

私が単純に行うことはlang、テーブルにフィールドを追加することです。

次に、そのフィールドをフィルタリングします。

SELECT * FROM articles WHERE lang = 'en'

ユーザーが言語を切り替えることができる管理セクションの CRUD でも使用しており、その特定の言語のすべてのエントリが表示されます。

そして編集者は、自分が使用している言語のコンテンツに対して自動的に作業します。

INSERT INTO articles VALUES('My Title', 'My Article', 'en')

そして、単にユーザーの現在のローカルから「en」を取得します。（フォームを変更してオーバーライドすることは許可しています）。

于 2014-04-17T21:13:32.937 に答える