複数のデータ テーブル ソリューションのセットを使用する以外に、他のソリューションはありますか?データベースから読み取られるすべてのデータが多言語であることを確認する必要があります。
複数のデータ テーブル ソリューションのセットを使用する以外に、他のソリューションはありますか?データベースから読み取られるすべてのデータが多言語であることを確認する必要があります。
複数のデータテーブルセットを使用することはまれです。通常、言語ファイルが使用されます...データベースはキーのみを保存し、それらをカテゴリテーブルなどの翻訳キーワードに自動的に変換します
category.id = 1, category .name = ' デモ', category.slug = デモ, category.meta = 'これはデモです'
対応する翻訳ファイル
category_id_1_name = 'デモ'
category_id_1_meta = 'これはデモです'
必要に応じて、独自の翻訳ファイルを開発できます言語ファイル管理ページにありますが、一般的にはPOなどのエディタを使用できます。
もちろん、新しいテーブルを作成する代わりに追加の言語フィールドを必要とするドキュメントなど、この方法では処理できないものもあります。たとえば、記事テーブルには ID、言語、タイトル、コンテンツなどが含まれ、さまざまなドキュメントのリストは表示中に言語に応じて自動的にフィルタリングされます。
要約すると、単純な翻訳には言語ファイルが使用され、複雑なデータには言語フィールドが追加され、異なる言語のコンテンツは複数のレコードとして管理されます。
「データベースから読み取られるデータはすべて多言語対応」については、このソリューションは面倒すぎて、データベースに大きな負担がかかり、データ保守の量も多く、柔軟性に欠けます。通常、翻訳はデータベースの作業ではなく、インタラクションを最適化するためにフロントエンドによって使用されるソリューションであると考えられます。同様の問題には、通貨変換、数値形式、日付形式などがあります。データベースに依存する必要がありますか?新しい製品を作成し、3 つの異なる形式で価格を節約しますか?考えるだけで疲れてしまいます。