i18n をサポートする方法をよく考えた後、別のテーブルを持つという受け入れられた解決策の 1 つを思いつきました。
Translatable の問題
提案どおりにドクトリン拡張機能から Translatable をインストールしましたが、希望どおりに動作せず、経験豊富なユーザーから使用しないようにアドバイスされました。別のテーブルがある場合でも、メイン テーブルと変換テーブルの両方に翻訳可能な列があり、値を eav の方法で格納します。また、デフォルトのロケールが変更された場合（それが私に起こり、再び起こる可能性があります）、メインテーブルのデフォルト値にロケールが指定されていないように見えるため、事態が複雑になります。また、翻訳可能なフィールドがいくつかあります（5〜）。または、フォールバックの場合はさらに多くの左結合。
その他の解決
策私が考えた他の解決策は、各テーブルの翻訳のみを含む個別のテーブルを用意し、おそらくpostLoadイベントリスナーを介してデフォルトのロケールとフォールバックを設定することです。 ].getTitle() 、ロケールを提供する必要はありません。
問題
このアプローチの問題は、フォールバックです。回避策の 1 つは、たとえば、参加中に "WITH ロケールを ('en','de') に追加することです。これにより、より多くのデータが返されますが、フォールバックは機能します。他の方法では、合体を使用していますが、教義がエンティティでそれをマップすることは不可能です.フォールバックを効率的に実装する方法はありますか?