あなたの要件：
サイトが
認証されたユーザーとして複数の言語で動作するに
は、サイトのコードベースで見つかったt（）関数で実行されたすべての翻訳呼び出しを一度に翻訳できる必要があります。
その要件の説明は、あなたが求めているものに近いものですか？
クローラー
誰かが言ったように-クローラーは理論的にサイト全体を通過して、すべてのt（）呼び出しの登録を強制できます。しかし、1）クローラーはどのページをクロールするかを知りません。2）したがって、クロールするページのリストを維持するつもりはありません。3）クローラー、ピリオドを使用したくない。うわー ただ、うわー。正しい？
問題
- すべての翻訳文字列のリストはありません。
- Drupal / PHPは、コンパイルされたCとは異なり、動的言語です。たとえば、このコードベース全体をコンパイルしてから、この関数のすべてのインスタンスを見つけて
t()、データベースにそれらのインスタンスを登録し、登録されたすべてのインスタンスをt()一度に翻訳します。私たちがテーブルに持っている選択肢ではないと思います。
- クローラーが無力になるのと同じ理由で、静的コード分析ツールは無力になります。
t()このファイルでこれを見つけました。すごい！どのURLで使用されていますか？コンテキストは何ですか？
現在のツール（Drupal、および一部のcontribモジュール）、および現在の制約（リアルタイムテーマ呼び出し->テンプレートファイル-> t()呼び出しに依存）で問題を攻撃することは、ここで出口のない路地のように見えます。箱から出して少し考える必要があるかもしれません。
私たちの必要なもの
- 現在の翻訳文字列とそのコンテキストを教えてくれるデータソース、モデルが必要です-
- 積極的なデータモデル。現在のデータモデルはリアクティブです（呼び出しが
t()発生するたびにモデルが更新されます）。予防的なデータモデルが必要です。これはt()、実際に顧客によって実行される前に、アプリケーションがインスタンスを探す処理を行うモデルです。
- コンテキストが必要です。
t()単独ではそれをカットしません-なぜなら-私たちは「foo」を翻訳していることを知りませんが、私たちが翻訳しているターゲット言語はt()発生する場所のURLに依存します。t()たとえば、ラッパー呼び出しを使用して、ターゲット言語を呼び出しにハードコーディングできたとしても、目的には機能しません。
私たちが持っていれば-私たちの問題を助けるツールのいくつかを特定しました。これらのツールを使用して、データモデルに移動して、「まだ入力されていないすべての文字列をラップしてください」と言うことができます。次に、これらの翻訳を挿入します。ありがとうございました。t()
そして、顧客が次に来るとき、翻訳はそこにあります。
これらのツールをどのように構築しますか？
制約
- ターゲット言語をテンプレートに含めることはできません。これはURLによって決定されます。文字列がすべての言語をサポートする必要があると仮定します。
- 翻訳された文字列をテンプレートに含めることはできません。翻訳はデータベースに保存されます。
問題をより深く考え、いくつかの課題と制約を特定したので、利用可能なソリューションを調べたり、カスタムソリューションを作成したりすることを検討できます。
ソリューションブレーンストーミング
「すべて」を結び付けるものが必要です。エンティティはどうですか？
- エンティティは、翻訳が必要な製品を保持できます。
- エンティティは、翻訳が必要な製品とそのコンテキストとの関係（接着剤）を提供できます。
- エンティティは、たとえば、フィールドに製品のデフォルトURLロケーションを指定できます。
- トークンを使用して、製品が表示される代替の場所（言語？）を指定できます。
- エンティティは、必要なプロアクティブなデータモデルとそのコンテキストを提供します。これにより、データベースにアクセスし、すべての製品エンティティを取得し、フィールドX、Y、およびZの翻訳文字列がない場合は、それらの翻訳文字列を作成できます。
その後、顧客が/pl/product/200を取得すると、データベースにアクセスして製品200を検索し、既存のpl翻訳を取得します。その製品のタイトルとキャプションのフィールドもありますか？翻訳もそこにあるはずです。
ここで使用している翻訳モジュールに関して、私は非常に曖昧で一般的です。独自の翻訳モジュールを使用することになる可能性が非常に高くなります-これはほとんどの場合です。これまでにDrupalで見たすべての翻訳モデル（D7の時点ではまだD8を見ていない）は、リアクティブであり、プロアクティブではありません。
手短に
理論的には、必要なものを構築するためのツールがあり、エンティティはすべてを結び付ける重要なコンポーネントです。-データ（翻訳文字列）、-ターゲット言語。製品言語の場合、エンティティ自体、できれば分類法のボキャブラリーを使用する必要はありません。または、他のエンティティの一般的な分類法もあります。- 環境。エンティティが表示されるURL。URLにはトークンが含まれ、トークンはターゲット言語の分類を参照します。
これらの3つの要素を使用すると、すべてのproductエンティティをURL alias取得し、フィールドに移動し、 分類トークンを取得し、可能なすべての用語の組み合わせを循環し、非常に大きない形式またはAJAXを使用して現在のユーザーにすべての組み合わせを提示します。マルチステップフォーム（そのようなもの）、および現在ログインしているユーザーが製品200のさまざまな言語を翻訳するときに、それらをデータベースに保存します
データベース内のどこかに、エンティティのフィールドAPIフィールド、各エンティティに属する設定フィールド（正確にはフィールドAPIではありませんが、データを保持できます）、またはこれに使用する別のテーブルがあります。データをエンティティに保存すると、コードとデータの両方が整頓され、簡単になります。
構築：可能な解決策
- D8MI（Drupal 8 Multilingual Initiative）
- カスタムコード：利用可能なバンドルおよび関連するテーマフックの実装をプログラムでクエリおよびレンダリングすることにより、t（）によってテンプレートで利用可能になる「インデックス」翻訳。
擬似コード
Foreachエンティティ（タイプx）、
すべての言語の検索（分類または製品に関連するコア言語）、
エンティティのレンダリング
-t（）の翻訳文字列を検出するために-renderの
theme（）を呼び出します。製品データモデル自体ではなく、製品。
結果：
-各言語でエンティティテンプレートをレンダリングする最初の呼び出しは、各呼び出しのデフォルトの言語実装を返します。
-テンプレートのt（）パラメーターがDrupalにキャッシュされ、翻訳の準備ができました（各製品インスタンスではなく、各言語インスタンスに対して）。
-「translator」ロールを持つユーザーは、翻訳インターフェイスに移動して、使用可能なすべてのt（）パラメーターを言語ごとに翻訳できるようになりました。
-サイト所有者は、顧客が各製品ページにアクセスするのを待つ必要も、手動で各製品ページにアクセスする必要もありません。これは彼がプログラムで行ったためです。
未解決の質問：
-コンテキストとは何ですか？「製品」エンティティバンドルごとにtheme（）をプログラムで呼び出すと、呼び出し元の場所が記録されますか？ノードのURLを記録しますか？「コンテキスト」を変更できますか？コンテキストはどこに記録されますか？「動的な」テンプレートを使用するとどうなりますか。つまり、製品ごとに複数のテンプレートがある場合、それらのバリエーションをどのように検出しますか。
いつものように、理論化と擬似コードはブレーンストーミングにのみ適しています。しかし、プロトタイピングを開始するまで、開発段階では実際に何に直面しているのかほとんどわかりません。いくつかの制約、考えられる解決策、考えられる問題や質問を作成したので、概念実証または作業プロトタイプの実装に進むことができます。上記の未解決の質問のいくつかは、この方法でしか答えることができず、プロトタイプの最も早い段階（成功または失敗に関係なく）で、それらの質問のいくつかに答え始めることができます-または、アプローチをすべて変更できます。お楽しみに〜
wget何でも使用します。ハックが、あなたはそれが許可されたと言った（：